https://bugs.documentfoundation.org/show_bug.cgi?id=80659
--- Comment #43 from Armin Le Grand (CIB) <[email protected]> ---
Yes, it should be cached, but please not in the app (Writer) as it was in the
elder days. The orig bm data has to be available in the render stack, so that
hw scaling can use it if available.
Thus there are two places to cache this:
(a) In the primitive stack
(b) in the sys-dependent part of GDI
I would (of course) opt for (a) since I know that would work (sys-independent).
In principle it is about:
- Add a decomposition (the scaled bitmap or part of it) to the bitmap primitive
- Use a even-more-lo-level Scaled/Buffered/Cahed/BitmapPrimitive to hold this
- do intelligent caching (only needed stuff, re-use as long as cerain zoom did
not change too much, flush when using too much mem, ...)
- In a primitive renderer, use the bitmap primitive if HW scale is available,
the (cached) decomposition else (sys-dependent flag?)
- Make use of mechanisms supporting this in the primitive stack
BTW: I checked and indeed even on Win still some paths go to sw-scaling - sigh
- but that can be corrected. This is a argument to think about sys- and
task-specific renderers, e.g. a *direct* GdiPlus-one for Win, *not* taking the
path over VCL at all. Think about a big primitive renderer factory which you
give info what you want (win and screen render) -> gives you the primitie
renderer for GdiPlus and Win. Same for Linux, same for online, same for
headless, same for PDF export (ah dreaming...)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
