https://bugs.documentfoundation.org/show_bug.cgi?id=80659
Michael Meeks <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Non-accelerated image |Non-accelerated /
|scaling under Linux ... |non-cached image scaling
| |...
--- Comment #41 from Michael Meeks <[email protected]> ---
Removing the Linux specific piece here - see bug#88302 - which appears to shows
the same result on Windows ( I guess in the GDI fallback paths ).
Also - AFAICS we really should consider caching the scaled images; most images
are rendered only once, at one size - and at one zoom level - and relying on
hardware to continuously do high quality interpolations is not great - even
with GL acceleration - once we get to a largeish scale-factor, we have to do
multi-pass scaling which is poorer quality and performance; IMHO we should be
caching.
I snip some hearsay / design bits from a friend:
[snip]
The best would be to cache the scaled down version somewhere around
SwNoTextFrame::PaintPicture
paintGraphicUsingPrimitivesHelper begins the chain of the slow path; and yet we
are highlevel enough to have some good insight into the management of the
bitmaps etc.
Like, already here we know what outputdevice is targeted in the end, so we can
do the scaling here (so that it fits the target outdev), and remember the
scaled bitmap somewhere - probably directly in the pGrfNd (together with the
information about the target outputdevice).
And use the scaled-down version if the outputdevice has the same settings (like
resolution and stuff) instead of calling drawinglayer with the verbatim pGrfNd
[/snip]
Would love feedback on that.
--
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
