[00:00.000 --> 00:16.880]  Hello, my name is Armin Legrand.
[00:16.880 --> 00:24.000]  I'm working on the graphic stack for a long time, as many of you know, and this is actually
[00:24.000 --> 00:29.440]  also a kind of update from the LibreOffice conference where I already talked about system
[00:29.440 --> 00:33.000]  dependent primitive renderers and why they are important.
[00:33.000 --> 00:41.280]  I'm talking about them for years, as you know, and at the last conference I was so,
[00:41.280 --> 00:48.480]  I wish to promise to implement a prototype, and I did, and it's finished, and I did it
[00:48.480 --> 00:58.360]  on Direct2D, and it renders what you expected to render, so with Direct2D, of course, it's
[00:58.360 --> 01:04.520]  on Windows, but there was no special reason for Direct2D, I just wanted to try out if
[01:04.520 --> 01:13.720]  it fits well to a standard graphic library, and if I could figure out how to do it myself
[01:13.720 --> 01:23.120]  because I didn't know Direct2D too good myself, so it was some safe training too.
[01:23.120 --> 01:33.280]  So it's finished, it's working, and everyone can have an example now how to do some system
[01:33.280 --> 01:36.280]  dependent primitive renderer if he wants to.
[01:36.280 --> 01:38.040]  So what happens when painting?
[01:38.040 --> 01:46.440]  I don't want to go in detail about that, I have tried to formulate what's all happening
[01:46.440 --> 01:54.520]  so you can just check it when you download the presentation, that's the history, why
[01:54.520 --> 02:03.160]  it happened, what happened, also some history, so what did I do?
[02:03.160 --> 02:10.560]  Just started with a simple primitive processor, and it's feature complete because it supports
[02:10.560 --> 02:18.160]  all necessary primitives, there are four primitives you have to support, and some grouping primitives
[02:18.160 --> 02:24.280]  you have to support, and there are quite some extra primitives supported to get some more
[02:24.280 --> 02:29.720]  speed into it, which is not necessary to be feature complete because as I hope you know
[02:29.720 --> 02:36.360]  all now, you can decompose a primitive and it just dismantles the simpler primitives
[02:36.360 --> 02:39.480]  which can then be rendered.
[02:39.480 --> 02:47.920]  So it's in a single source file, so no hacking required, inside this single source file you
[02:47.920 --> 02:54.320]  can do whatever you want, it's just 2000 lines, so not too much if you compare it with some
[02:54.320 --> 03:00.840]  back end implementations which are spreaded over the whole office.
[03:00.840 --> 03:10.320]  It translates primitive data directly to direct2d, uses already available system dependent
[03:10.320 --> 03:16.640]  buffering which was not used in other implementations, I don't know why because it's working and
[03:16.640 --> 03:23.120]  available, it does not need any adaption of bitmap-bitmap-x which of course would be
[03:23.120 --> 03:29.320]  even better to do, so to directly use the data without converting it, but now it's just
[03:29.320 --> 03:34.760]  converted once and held in this standard system dependent buffer.
[03:34.760 --> 03:38.960]  So it's quite fast and you can try yourself because it's in the master, so if you have
[03:38.960 --> 03:44.760]  a Windows Pro version and you started with environment variable mentioned here, you will
[03:44.760 --> 03:50.280]  get the new renderer and you will see the added view of your impasse and the parts of
[03:50.280 --> 03:57.720]  wider and calc as far as say support primitive rendering rendered directly by direct2d without
[03:57.720 --> 04:03.640]  using output device at all, so that's proof of concept and I delivered it.
[04:03.640 --> 04:14.920]  So now I hope we find some guys who can help, these are the ones I added to make it faster
[04:14.920 --> 04:22.280]  and it's not even optimized but already pretty fast because just think about the layers which
[04:22.280 --> 04:29.280]  I used, we have the model, it creates primitives, the primitives are thrown at a renderer currently
[04:29.280 --> 04:38.920]  to the VCL pixel renderer, that renderer packs it to output device, still to output device
[04:38.920 --> 04:44.800]  and that output device sends it to a back end, so you have a five level stack and output
[04:44.800 --> 04:53.760]  device alone does a lot of work in between, old, unmaintainable, incredible stuff in between.
[04:53.760 --> 04:59.960]  So what a system dependent primitive renderer does, it removes the three last steps and
[04:59.960 --> 05:07.520]  packs it into one, you go directly to the renderer you want, in this case direct2d.
[05:07.520 --> 05:11.000]  So what does it look like when you let it run?
[05:11.000 --> 05:17.800]  It looks the same and that was exactly the target, it looks the same but it's fast and
[05:17.800 --> 05:20.600]  it does not use output device.
[05:20.600 --> 05:25.680]  So what else can be done, currently it has no support for text, so text is decomposed
[05:25.680 --> 05:32.600]  and rendered as anti-aliased poly polygons, not too bad but of course for production
[05:32.600 --> 05:40.560]  state we would need something more and direct support for gradients, so for direct2d I already
[05:40.560 --> 05:46.040]  looked a little bit into it, it might just be done as a custom effect which is some kind
[05:46.040 --> 05:54.080]  of texturing, so with some more work this could easily be extended to product quality.
[05:54.080 --> 06:00.800]  Let's see if we find resources to do with this this time.
[06:00.800 --> 06:07.240]  So what also happened, Kralen started a system dependent primitive renderer on Kyro, thanks
[06:07.240 --> 06:16.600]  Kralen, you're my man, so he just tested out by copy pasting the structure and filling
[06:16.600 --> 06:21.680]  it out with Kyro stuff and it does render something, there are some caveats and it would
[06:21.680 --> 06:28.120]  need some more love but it's easy maintainable and can be extended, so another proof of concept
[06:28.120 --> 06:37.760]  says this really works well, so in the process I also did some upstream clean up stuff in
[06:37.760 --> 06:42.160]  the master which was in the race, it was another reason to do this proof of concept
[06:42.160 --> 06:49.240]  and prototype, I can no promise that you can do exactly the same in drawing layer and do
[06:49.240 --> 06:57.000]  your own system dependent primitive renderer for any target system without having to fear
[06:57.000 --> 07:01.880]  that you get hung on something in the master which would be in the way because I had to
[07:01.880 --> 07:07.520]  clean that up anyways.
[07:07.520 --> 07:12.360]  The other point is this is good for any few visualizations but what about the rest which
[07:12.360 --> 07:23.480]  is still painting using output device, so I did two more experiments, one is forward
[07:23.480 --> 07:30.040]  calls in the back ends, so the back ends has for lean API, I just made a proof of concept
[07:30.040 --> 07:36.680]  prototype, you can find it in Garrett with the link I gave, you can add it as a patch
[07:36.680 --> 07:42.960]  to the current office, compile it and see it running and you will see that it currently
[07:42.960 --> 07:52.160]  forwards a single method to a rectangle for test and to make it visible in the office
[07:52.160 --> 07:58.480]  it's just a little bit color coded so we can see it, so that works perfectly and the good
[07:58.480 --> 08:04.360]  thing is the back ends are libraries themselves, you can just link them against a drawing layer
[08:04.360 --> 08:09.640]  and all functionality can be in drawing layer and you are storing layer stuff.
[08:09.640 --> 08:16.720]  The other way I tried was a kind of draw forwarder in the output device itself, so for every
[08:16.720 --> 08:23.200]  paint command call something in a virtual structure which is then overloaded in output
[08:23.200 --> 08:31.240]  device also works flawlessly and I also used the direct again and this is proof of concept
[08:31.240 --> 08:36.320]  too, there is also a Garrett link, you can just use that link, patch it into your office
[08:36.320 --> 08:46.920]  compile and see it running, you get the same color styling to see how it's running, yeah.
[08:46.920 --> 08:55.000]  So which way to continue, best convert all to LibreOffice primitives, I always wanted
[08:55.000 --> 09:02.560]  to have said done but I know it's not possible, combination of one of these solutions with
[09:02.560 --> 09:09.120]  system dependent primitives or worst just keep it like it is, like always.
[09:09.120 --> 09:16.120]  So I'm still very interested to do this but I did this prototype now mostly in private
[09:16.120 --> 09:25.480]  with some support from Torsten thanks but I cannot continue doing it in the needed intensity
[09:25.480 --> 09:31.800]  just privately so without getting resources this will fail again and we will stay at VCL
[09:31.800 --> 09:35.880]  output device forever, that's it.