So I have a plan of attack that will alleviate some of these problems. 

It’s really a two pronged attack, which is actually just a gradual migration of 
code that can be done gradually. The two tasks are:

Task: migrate fallback code out of OutputDevice and into SalGraphics.

I have already started to do this here: 
https://gerrit.libreoffice.org/q/topic:%22SalGraphicsFallback%22+(status:open%20OR%20status:merged

Parallel task: decouple metafile recording from drawing functionality

My plan for this is to do the following:

1. I create a RenderContext2 class which OutputDevice derives from
2. Carefully and gradually move the drawing code into parallel drawing 
functions in RenderContext2. I keep the metafile recording functionality in 
OutputDevice and have it call on the parallel RenderContext drawing function.

What this essentially does is implement a decorator pattern. This can be done 
gradually. In fact, when I looked at the code, the sequence of drawing 
functions look like they should be:

a. state and mapping functions - beginning with push and pop, then the 
functions that set line colour, etc.
b. clipping functions
c. line and pixel drawing functions
d. Ellipse, arc, pie and chord drawing functions
e. Rectangle drawing functions
f. Polygon drawing functions
g. Polypolygon drawing functions
h. Polyline drawing functions (this will be more tricky)

The rest will be trickier to migrate and require a fair amount of refactoring 
to seperate them. I fully expect a bit of code duplication for a short time 
whilst the metafile code is seperated from the drawing code.

Parallel task (and should be an easy hack, I would have thought): remove or 
migrate unnecessary code out of OutputDevice

For this task we need to look at code that is not strictly necessary for 
RenderContext2 and OutputDevice. Things like making a gradient grayscale, which 
should be migrated into Gradient. That sort of thing.

After this we need to start to tackle the issue of having to push state around. 
IMO, we seem to have done this because that’s the way a meta file does things. 
I do t believe this is necessary. If we want to use a coloured line, then we 
tell the function what colour it should use as a function parameter. If we need 
a full colour, then we do the same. If we don’t care we pick sensible defaults.

Once we have a largely stateless class, then our next part of the process is to 
work out what to do with the alpha handling part of the code. For that I have 
no real ideas. A temporary solution would be implement another decorator class 
to seperate the concerns, but IMO that work is less important than migrating 
fallback code to SalGraphics and separating metafile processing from drawing.

Chris


_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to