We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

LibreOffice graphics subsystems - SystemSpecificRenderers

00:00

Formal Metadata

Title
LibreOffice graphics subsystems - SystemSpecificRenderers
Subtitle
Providing a working Example and report about progress/findings during development
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Lecture/Conference
Physical systemCodeImplementationOffice suiteLatent heatVolumenvisualisierungFunction (mathematics)Link (knot theory)Single-precision floating-point formatHacker (term)Front and back endsSource codeBitRectangleComplete metric spacePatch (Unix)Primitive (album)PrototypeProof theoryView (database)Point (geometry)Presentation of a groupVolumenvisualisierungLink (knot theory)Data structureFunction (mathematics)Texture mappingGradientProduct (business)PolygonCASE <Informatik>Set (mathematics)Physical systemPixelEndliche ModelltheorieDatenausgabegerät1 (number)MereologyImpulse responseIntegrated development environmentCombinational logicRevision controlWindowGraph coloringBuffer solutionStandard deviationSystem callFunctional (mathematics)Library (computing)Adaptive behaviorImplementationComputer animationLecture/Conference
Program flowchart
Transcript: English(auto-generated)
So, hello! Oh, it vanished. Okay. Ah, it reappeared. So, hello, my name is Armin Legrand, I'm working on the graphics stack for a long time, as many of you know, and this is actually
also a kind of update from the LibreOffice conference, where I already talked about system dependent primitive renders and why they are important. I'm talking about them for years, as you know, and at the last conference I was so... I wished to promise
to implement a prototype, and I did, and it's finished, and I did it on Direct2D, and it renders what you expect it to render. So, with Direct2D, of course, it's on Windows, but there was no special reason for Direct2D, I just wanted to try out if it fits well to
a standard graphic library, and if I could figure out how to do it myself, because I didn't know Direct2D too good myself, so it was some self-training too. So, it's finished, it's working,
and everyone can have an example now how to do some system dependent primitive render, if he wants to. So, what happens when painting? I don't want to go in detail about that. I have
tried to formulate what's all happening, so you can just check it when you download the presentation. That's the history, why it happened, what happened. Also, some history. So, what did I do? Just started with a simple primitive processor, and it's feature complete
because it supports all necessary primitives. There are four primitives you have to support, and some grouping primitives you have to support, and there are quite some extra primitives
supported to get some more speed into it, which is not necessary to be feature complete because, as I hope you know all now, you can decompose a primitive and it just dismantles to simpler primitives, which can then be rendered. So,
it's in a single source file, so no hacking required. Inside this single source file, you can do whatever you want. It's just 2,000 lines, so not too much if you compare it with some backend implementations, which are spreaded over the whole office. It translates primitive
data directly to Direct2D, uses already available system dependent buffering, which was not used in other implementations. I don't know why, because it's working and available. It does not need any adaption of Bitmap, BitmapX, which of course would be
even better to do, so to directly use the data without converting it, but now it's just converted once and held in this standard system dependent buffer. So, it's quite fast, and you can try yourself because it's in the master, so if you have a Windows Pro version and you started with the environment variable mentioned here, you will get the new renderer,
and you will see the added few of door impulse and the parts of writer and calc, as far as, say, support primitive rendering, rendered directly by Direct2D without using output device at all. So, that's proof of concept, and I delivered it. So, now I hope
we find some guys who can help. These are the ones I added to make it faster, and it's not even optimized, but already pretty fast, because just think about the layers
which I used. We have the model. It creates primitives. The primitives are thrown at a renderer, currently to the VCL pixel renderer. Set renderer packs it to output device, still to output device, and set output device sends it to a backend. So, you have a
five-level stack, and output device alone does a lot of work in between old, unmaintainable, incredible stuff in between. So, what a system-dependent primitive renderer does, it removes the three last steps and packs it into one. You go directly to the renderer you want,
in this case Direct2D. So, what does it look like when you let it run? It looks the same, and that was exactly the target. It looks the same, but it's fast, and it does not use output device. So, what else can be done? Currently, it has no support for
text. So, text is decomposed and rendered as anti-aliased poly polygons, not too bad, but of course for production state, we would need something more, and direct support for gradients. So, for Direct2D, I already looked a little bit into it. It might just be done as a
custom effect, which is some kind of texturing. So, with some more work, this could easily be extended to product quality. Let's see if we find resources to do with this this time.
So, what also happened? Kralent started a system-dependent primitive renderer on Cairo. Thanks, Kralent. You're my man. So, he just tested out by copy-pasting the structure and filling it out with Cairo stuff, and it does render something. There are some kfolds,
and it would need some more love, but it's easily maintainable and can be extended. So, another proof of concept says this really works well. So, in the process, I also did some upstream cleanup stuff in the master, which was in the race. It was another reason to do this proof of concept and prototype.
I can no promise that you can do exactly the same in drawing layer and do your own system-dependent primitive renderer for any target system without having to fear that you get hung on something in the master, which would be in the way, because I had to clean that up
anyways. The other point is, this is good for edit view visualizations, but what about the rest, which is still painting using output device? So, I did two more experiments. One is forward
calls in the backends. So, the backends has for lean API. I just made a proof of concept prototype. You can find it in Garrett with the link I gave. You can edit as a patch to the current office, compile it, and see it running, and you will see that it currently
forwards a single method to our rectangle for test, and to make it visible in the office, it's just a little bit color-coded so we can see it. So, that works perfectly, and the good thing is the backends are libraries themselves. You can just link them against a drawing layer,
and all functionality can be in drawing layer and use drawing layer stuff. The other way I tried was a kind of draw forwarder in the output device itself. So, for every paint command, call something in a virtual structure which is then overloaded in output device also works
flawlessly, and I also use the draw rect again, and this is proof of concept too. There's also a Garrett link. You can just use that link, patch it into your office, compile, and see it running. You get the same color styling to see how it's running.
So, which way to continue? Best convert all to LibreOffice primitives. I always wanted to have that done, but I know it's not possible. A combination of one of these solutions
with system-dependent primitives or worst, just keep it like it is, like always. So, I'm still very interested to do this, but I did this prototype now mostly in private with some support from Torsten, thanks. But I cannot continue doing it in the needed
intensity, just privately. So, without getting resources, this will fail again, and we will stay at VCL output device forever. That's it.