Hi,
looking at fdo#38814 "Snappier rendering: paint at idle, not on timeout"
https://bugs.freedesktop.org/show_bug.cgi?id=38814
it is not clear to me why we handle resize asynchronously.
It was introduced in
http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb72a53dc6ff64001cbdebbdd908b7cf71aa8723
"#83524# buffer resize events to handle opaque resize WMs better"
only for vcl/unx/generic.
Then there was a bug
https://issues.apache.org/ooo/show_bug.cgi?id=30571
"VCL plugin: slow painting of help application if main window is resized"
- turned out the help app is super-slow on Resize -> the solution was to
resize on timer for *all* platforms/vcl plugins:
http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=i30571
So - #83524# is dead, I don't know what is "opaque resize WM"... But if
there is a problem with the help application only, wouldn't it better to
fix *its* resize handling?
FWIW, I've disabled the resize timer (i.e. bool bStartTimer = false in
vcl/source/window/winproc.cxx) and don't see any problem so far (except
the help app).
Same for layout - I guess it can be done immediately..? (Well, the
printdialog will need some love then).
Opinions?
Regards,
Ivan
Context
- resize handling / layout on timeout? · Ivan Timofeev
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.