Problems with OutputDevice

[Chris Sherlock]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20210101/fc3ea55f/attachment.htm>