 Some presentation from 2006 and there must have been much work even before that, so it is really getting old even today. So, first of all, I will show you an example of how the use of drawing layer looks like. So, one more thing, by drawing layer, when I talk about that, I mean the lowest part of the drawing stack in LibreOffice. So, in the case when I talk about drawing layer itself, it means the mean how you get something on the screen. But then, when you have shapes in the documents and stuff like that, it is sometimes called drawing layer as well. But for the purposes of this presentation, I call it SDR objects, so that it's a bit more visible that it is not the entire drawing layer itself. So, when you want to use drawing layer, in this case, it is when you want to draw this hatching example. So, what you do here is that you draw a shape with the hatching and then you draw a rectangle, a black rectangle around that. So, the code that actually does that is something like this. So, first of all, you create something that is called primitive. In this case, hatch primitive, so that is for now something that will create hatching in the polygon that is defined by this rectangle. So, that's the first thing, you create that. Then, you will create, on this mistake, not the hatch primitive, but of course the rectangle. So, you create some polygon hairline primitive 2D, which is in this case, again, just the rectangle because you do not provide it with some fancy polygon, but only with the rectangle. So, you create these two things and then you put it in some kind of display list. So, that's just a sequence of things you want to draw and it defines the order of this drawing. So, you will first draw the hatch primitive and then, on top of that, this rectangle, this black rectangle around that. Then, well, because this is a real code, this is in XtapHCSS Online 121. So, you can see there, I've stripped only just some initialization of a virtual device here. So, you create the processor, which is something that will somehow display or in this case draw into the virtual device. Whatever you have in this sequence, so in this, like, display list. And, yeah, so that's happening here, so you do the process of the sequence. So, this consequence will create the shape I've shown on the previous slide with the hatching and the rectangle around that. And now, you have it in the virtual device, so you create a bitmap from that and trigger that. So, this is because it is used by the widget that needs the bitmaps there. So, it is not drawn directly on the screen, but into an intermediate bitmap and this is handled by the widget itself. So, I've used some terms here. So, what are primitives? Primitives are classes that represent the shape in some way. The primitives, like, there are actually two sets of primitives. One set are basic 2D primitives, so these are that cannot be decomposed into anything more simple. So, as the drawing layer is now, the basic 2D primitives are bitmap 2D, which is some bitmap. Then point array, single points, then hairline, that's just the line. It's like as thin as possible, whatever the device allows you to do. And then poly-polygon core primitives, so some kind of core polygons. But then, you can have more primitives, which are not that primitive anymore, but, well, which are created from these basic primitives. In order to be able to do that, the primitives have to define a decomposition. So, they have a method that creates the display list. As I've shown you, this primitive sequence of how to create this one primitive from the previous primitives, from the basic primitives. You can do some groupings there, you can nest it even more. So, you can create decomposition that decomposes into something more and more complex to most primitive. The advantage of this is that when I will be talking later about creation of your own primitive, you can define it on one place and when you provide the decomposition, it is supposed to just work. The disadvantage is that, of course, in many cases you need some special behavior, so then it is getting much more complex. One example of this kind of primitive is the polygon marker primitive, which is the direct handler around objects that shows that this is selective. You can resize it, move it away, or something like that. So, that looks in LibreOffice like a dashed rectangle around objects. So, this one is just composed into the two poly-polygon airlines. So, one defines the dashes and the other what is between dashes. So, that looks like that. Then you have the processes. As I've shown you in the code example, you have the processor to be able to get it somehow on the screen or into a bitmap or into a virtual device. So, there are various processors that do this. So, one of the most important one is the pixel processor which is supposed to just render it on the screen. So, you provide it with the primitive 2D sequence and it is supposed to either do the compositions or render it directly onto the screen. Another one which is quite important for printing, for metafile exchange is the VCL metafile processor 2D, which creates the VCL metafiles out of these primitives that are important. And there are other special purposes. So, for example, for contours like when you need to or for heat testing. So, when you need to find out if the mouse was positioned over some primitive or not, there's a processor for that that acts according to the regular positions and finds for you like if you are inside or not. So, how to implement an own primitive? So, what does it mean? So, how to actually implement something that, you know, behaves in this way that allows you to draw something new on the screen? An example could be that if we wanted to provide shadows that are not this hard like, but instead blark so that you can see that the shadow is fading into the background. So, in this case you want to provide the primitive itself, which means you will provide some kind of storage for the information about how is it, like what is it supposed to contain. So, for example, in this case of the blark shadow you want to derive it from the bitmap primitive because if it is blark shadow the result will be some bitmap that just provides the blark content. But in this, the primitive itself will not contain the bitmap. It will only contain the information like what is the intensity of the shadow, what is the color of the shadow, it will not contain the bitmap itself. Then you have to create an ID for that and you have to implement also the decomposition of this. Even if it is something that, you know, like this shadow or what is it, a bitmap, you still need to provide it because some of the processors do not have to implement like some kind of direct drawing of the primitive. And then in case this is something as special as for example the blark shadow, you need to do a special case in the various processors that need that. Like the hit test processor most probably won't need anything special for the blark shadow because you do not care how it looks, you just need the information if it is inside or not. But for example for the showing on the screen it is pretty useful to just special case this and be able to draw it directly or combine it directly in some more optimized way than just to, you know, try to vectorize it in any way. So you have to find out which processors need to be modified this way and act accordingly. So where is the drawing layer used these days? So one is SDR objects which are the shapes that you have in draw or in impress or in writer as well that are these vector drawings. The selections use drawing layer so that when you select the text in writer that's using drawing layer as well. Then there are small cases like I've shown you in the example at the beginning just to show you some preview of anything. And then also it is used for custom widgets. So for example when you have these buttons for headers or footers in writer that appear when you click into the header this is done through drawing layer as well. So this is pretty much about the lower part of drawing layer. So did it make any sense? Okay that's great because we are going to get into parts that do not make that much sense to me. So I must say that I wasn't able to find all the details about the SDR objects unfortunately. So I attempted to write down here what I managed to find. But of course if you find anything more it will be most appreciated. After the talk I will also extract the text from this into the readme's that Michael talked about. But if you find more please do extend the readme's as well. So SDR objects these are as I've said these objects that you have in various locations. And internally like there's an abstract SDR object but there are many many SDR objects derived from that. So that's the hierarchy is quite deep as well here. So like from SDR object it is derived SDR attribute objects from that. So there is SDR text object from that SDR rectangle object and from that for example SDR circle object. So SDR circle object is in fact a rectangle which is a text which is a attribute object which is finally SDR object. So that is it. So this all builds some additional complexity on top of the drawing layer itself. I think it is not good to blame the drawing layer for this because the SDR objects were there before. It's something old and Armin was like designing that to actually use the drawing layer. And it seems to me that it is just like stuck somewhere in the middle of the rewrite or change. But it hasn't changed as much since 2006. So my hopes are not too high that this will ever be like finished to the state that was originally designed. So I think that we shouldn't be afraid of putting us in this area. If you like find your way into these things and want to change anything there. Just be not afraid. So I've actually covered most of the slides when I was talking showing the previous one. So the rework of SDR objects was in an attempt to move it to model view controller. At the times when the model view controller was the most sexy thing in the complete industry. And at the time they just wanted to separate the model and view. So there is no controller in this model view controller. The model itself is the SDR object and the SDR object contains a pointer to view contact. I was trying to find the definition of view contact like what actually this means. And there is no definition anywhere. It is always like if you are lucky then you find that it should do something. But it is not entirely defined like what is this something. So I unfortunately cannot tell you what the object is. But it is used by the SDR object to actually get the decompositions of the dry light shapes. So that is how is it used. But what it is actually or what was the purpose of introducing this. I have found that. Then there is the view object contact which is again something I didn't find the definition of. So this again works on the primitives. And this is supposed to provide you the decomposition themselves. So when the SDR object and view contact contains the hierarchies of the drawing layer of the drawing layer primitives. This view object contact somehow is supposed to break it down into the basic primitives and stuff like that. If you want to try to understand it a bit more. I've used this picture from this presentation from 2006 opening of this conference. And please do extend the readme. It will be most appreciated by everybody. The own primitives for SDR objects that extend the existing primitives that are in the drawing layers directory. They are defined in Svx source SDR primitive 2D. So you can have a look like how exactly the circles or ellipses are defined for example. And view contact, view object and view object contact is defined all or implemented all in Svx source SDR contact. It does the decomposition of the SDR objects and all sources of preparation of them. But as I say like the big picture still escapes me so sorry for that. So some drawing layer problems that I've seen so far or hit when I was lucky enough to have something to do with that. Is that in many cases the processors use these decompositions and compositing again. So in many cases like when working with transplants and trying to do something with transparent objects. You just end up like piling bitmap operations one on each other. So you get the bitmap, do some operation on that then create another bitmap from that. Which may be inevitable because there are limitations of what we see often do. The problem here is that the drawing layer itself or the primitives themselves do not have any idea of how it is being used and what is the device behind that. So if you wanted to cache that you just count because the drawing itself is created by the renderers but the renderers live only shortly. So you just create that, do some like the rendering of the primitives and then it dies again so you cannot just cache it in the renderer itself. That's something of a problem like recently there was a bug that just regressed the quality of bitmaps that we are showing in the application. Because it stopped to be anti-aliased. So I just wanted to introduce there some kind of nice scaling and I failed terribly because the performance was so bad that Microsoft had to revert that. So the correct solution here would be to cache the results, cache the bitmap directed for the output device that is being used. But there's no good place for that in drawing layer at the moment. The other problem is the complexity of the SDR objects. So as I've described that it's apparently halfway somewhere but it got somehow lost the common knowledge of like what is the final state that it should supposed to have. And so I think we should just like in case you feel like that try to understand more there, describe it in the readme and let's try to just read it up if you have the energy and built to do that. And yeah there might be much more that I haven't seen yet. But I'm sure that this is all fixed up so don't be depressed about that. So I think that when we will have more of the readme's and improved by other people as well that we will get somewhere and we will come up with a plan what to do with this. So yeah that's all it. So questions. So you are speaking about drawing patches and of course VCL also has an API for drawing patches. So in new code is it considered a bad practice to use the VCL API directly and the nice and expected ways to use the drawing layer or? That's a hard question. It's part that in most cases if people figure out to draw something that somehow then they are happy that they managed to do it and they don't care about the proper way. Yeah so that's very hard to say but the idea of drawing layer was to be able to have the abstract description of the object or of what is supposed to be drawn and then have the render that renders that. So in theory it should be simple like if everything was using drawing layer to just create one more renderer in case you wanted to do for example OpenGL drawing. So in this case because everything has its decomposition you would just implement the OpenGL rendering for the few basic primitives and you would have it basically working and then you could go into like more details and special case some of these primitives. So in theory it would be better to use drawing layer for these cases. In practice it is so that lots of things just uses VCL directly still. So if we wanted to move to the OpenGL we still have to first port VCL anyway and then provide the drawing layer as well as we have discussed. Mocky just stayed in the night because when you have these two then you are mostly covered for what you need. But I think that just at the very moment it just doesn't matter that much. Just because VCL also has this ability to get not a fire from the drone with the device and so on. So I see that it's a different API and I understand that ideally drawing layer is a bit parallel and the other one they physically do the same. Which one should we use? I would probably choose drawing layer just so that to get more understanding of that and see the shortcomings and what needs to be improved there and to learn something new. Because using VCL is easier. Using drawing layer is more complex. So if we want to improve the drawing layer we need to start using that so that we can see what we need to fix for our needs. Does it ask for it? Okay, are you possible? In the open office, does drawing layer finish the work of the modular new controller? We have cherry-crate just everything that OpenOffice has. Whatever the license allows us to do. If they have anything on top of this that we do not have, that's not the case. We have everything that is in the OpenOffice. From the point of view of drawing layer or any things like that. So now the state that there is only model and view is the same in OpenOffice as well. Any other questions? Thank you so much.