Fwd: ESC meeting agenda: 2020-12-17 16:00 Berlin time

From: Chris Sherlock <chris.sherlock79@xxxxxxxxx>
Date: 23 December 2020 at 8:38:27 am AEDT
To: Miklos Vajna <vmiklos@xxxxxxxxxxxxx>
Cc: libreoffice@xxxxxxxxxxxxxxxxxxxxx, libreoffice-qa@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: ESC meeting agenda: 2020-12-17 16:00 Berlin time

* Graphics architecture (Thorsten)
* https://pad.documentfoundation.org/p/ESC_graphics_architecture
* skia / vulkan metabug: https://bugs.documentfoundation.org/show_bug.cgi?id=129062
    + 13 (+1) open bugs, 141 total (+1)

* QA update (Xisco)
  + Please help flesh out the monthly reports:
        https://nextcloud.documentfoundation.org/s/2qbepFYXXan4ief

I hope I am not speaking out of turn, but one thing that might help in untangling VCL would be to ensure that the actual drawing work be done in SalGraphics, and not in OutputDevice.

I recently logged a bug here:

https://bugs.documentfoundation.org/show_bug.cgi?id=139170

The example given is that code that actually determines a polyline needs to be “emulated”. What this means is that the polyline and polygon rendering is ing done in OutputDevice and not in the various SalGraphics backends. In particular, the genpsp and X11 backends are the backends that don’t seem to handle things fully.

OutputDevice also seems to handle things that other classes should be handling - for example it seems to do more handling of bitmaps where I would have thought that the Bitmap class could handle the functionality.

Just a general comment. I have recently taken a stab at shifting some functionality out of OutputDevice and into Bitmap, but there is a lot I can see we could cull from OutputDevice.

Chris