> * 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
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
