Hello, my name is Armin Legrand.
I'm working on the graphic 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 renderers and why they are important.
I'm talking about them for years, as you know, and at the last conference I was so,
I wish to promise to implement a prototype, and I did, and it's finished, and I did it
on Direct2D, and it renders what you expected 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 safe training too.
So it's finished, it's working, and everyone can have an example now how to do some system
dependent primitive renderer 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 the 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 2000 lines, so not too much if you compare it with some
back end 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-bitmap-x 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 environment variable mentioned here, you will
get the new renderer and you will see the added view of your impasse and the parts of
wider 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, that renderer packs it to output device, still to output device
and that output device sends it to a back end, 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, Kralen started a system dependent primitive renderer on Kyro, thanks
Kralen, you're my man, so he just tested out by copy pasting the structure and filling
it out with Kyro stuff and it does render something, there are some caveats and it would
need some more love but it's easy maintainable and can be extended, so another proof of concept
says this really works well, so in the process I also did some upstream clean up 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 any few 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 back ends, so the back ends 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 add it 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 a 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 back ends are libraries themselves, you can just link them against a drawing layer
and all functionality can be in drawing layer and you are storing 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 used the direct again and this is proof of concept
too, there is 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, yeah.
So which way to continue, best convert all to LibreOffice primitives, I always wanted
to have said done but I know it's not possible, 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.