Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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


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.