LibreOffice graphics subsystems - SystemSpecificRenderers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/61556 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | |
| Genre |
FOSDEM 2023200 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Lecture/Conference
00:09
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
09:43
Program flowchart
Transcript: English(auto-generated)
00:05
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
00:24
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
00:43
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
01:07
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,
01:28
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
01:43
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
02:10
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
02:22
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,
02:42
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
03:02
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
03:23
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,
03:46
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
04:06
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
04:22
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
04:42
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,
05:05
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
05:24
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
05:44
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.
06:01
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,
06:21
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.
06:44
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
07:03
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
07:24
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
07:43
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,
08:04
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
08:25
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.
08:46
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
09:02
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
09:24
intensity, just privately. So, without getting resources, this will fail again, and we will stay at VCL output device forever. That's it.