resize handling / layout on timeout?
caolanm at redhat.com
Mon Oct 7 06:36:40 PDT 2013
On Sat, 2013-10-05 at 18:44 +0400, Ivan Timofeev wrote:
> looking at fdo#38814 "Snappier rendering: paint at idle, not on timeout"
> it is not clear to me why we handle resize asynchronously.
> It was introduced in
> "#83524# buffer resize events to handle opaque resize WMs better"
> only for vcl/unx/generic.
> Then there was a bug
> "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:
> So - #83524# is dead, I don't know what is "opaque resize WM"...
Opaque resize is the now normal case where window contents are shown
while moving as opposed to old-school drawing a simple empty wireframe
> 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)
Is the print dialog ultra slow after that or is there some other
Are you just on Linux or are you able to see what the general situation
is like on Windows/MacOSX too ?
More information about the LibreOffice