Apache OpenOffice (AOO) Bugzilla – Issue 42462
extremely poor rendering performance for non-trivial numbers of form controls
Last modified: 2017-05-20 11:13:49 UTC
With the attached spreadsheet - which implements approximately 250 list-boxes in a single sheet [ a cut-down version of a real-world use case ], we get staggeringly bad performance. * A big chunk of this seems to be the cost of instantiating the list-box - which (it seems) involves lots of X-server traffic some of it of very dubious usefulness [ setting window titles of unlikely-to-be-used floating windows etc. ] * Another chunk I imagine is possibly vcl not scaling very nicely to having a thousand-or-so peers of the one window; at destruction time we have a huge slow-down but perhaps that's via call-backs or somesuch. * scrolling is also really direly performing :-) * The main cause of the evilness though I think is the SdrPageView - which insists on instantiating (I assume 4 times over - due to the double sheet split ], hundreds of occluded controls. My profiles show time being consumed down this sort of path: SdrPageView ImpInsertControl() -> UnoControlContainer::addControl -> UnoListBoxControl::createPeer -> ListBox::ListBox etc. I'd be interested in an acceptable design to accelerate this; for example - it seems to me rather futile doing all this work immediately, when we could perhaps move the body of ImpInsertControl (wrt. control construction & placement) inside the SdrUnoControlRec - and instantiate all of that weight, only when the SdrUnoControlRec object becomes visible. Unfortunately given my limited understanding how how any of it works - it's rather difficult to work out what's going on; pwrt. the co-ordinate systems involved. I infer from the 'view' in 'SdrPageView' that there must be a per-view translation applied to all controls - to allow views to have different origins, but - that appears no-where to be the case. Either way - I'm interested in tackling this issue, but - will need some advice first.
Created attachment 22426 [details] a slow, slow file
Changed component.
Reassigned.
wg: since the poor performance seems to be isolated primarily in algorithmic badness in svx/ how then is this a spreadsheet bug ? Of course, I can spend some time generating a draw document that exhibits the same behavior [ I imagine ] - is that necessary ?
Hi Frank, as controls are your construction site this may be yours. Frank
Ah, form control performance ... Things I know so far about this (I investigated a while ago in the course of another issue): - One problem is that the ListBox in VCL creates a floating window all the time, even if not needed. Normally, we could argue that this window is only needed when the (drop down) list box is to really open its floater... Unfortunately, the whole ListBox architecture is based on the ImplWindow, whose parent is the floating window, even for (normally unrelated) operations. - The code at the very end of UnoWrapper::WindowDestroyed in toolkit/source/helper contains a loop over all top level windows which currently exist. Due to some outdated architecture in VCL, this has a complexity of O(n^3) (not only O(n^2), as you would assume), with n being the number of system windows. Unfortunately, the above-mentioned floating windows *are* system windows, so this sums up pretty quickly (a document with 2000 list boxes can take *hours* to open or close). This explains at least the performance problem when closing such a document, and in parts also when *opening* (where also all controls are created/destroyed/created for some reason). I have a patch for this O(n^3) problem, but not checked in, and it's missing some polishing requested by SSA, which I did not yet find time for. Immediate ideas: - Make the listbox not creating a floating window, unless really necessary. The VCL people did not dare :) to do this in the 2.0 time frame, due to some unforseeable risks associated with it. - create peers only if necessary, as suggested by you. I don't have the slightest idea whether and how this could work, since this touches areas of the drawing layer where our form controls are only "guests", and which I rarely needed to look at (it was there long before I inherited the code :). I cc Armin Le Grand here, who's our drawing layer expert. Nevertheless, I'm willing to help to work on this, not only 'cause I am pretty sure I can learn a lot 'bout the drawng layer here :)
And no, this is not really a spreadsheet issue, but spreadsheets seem to stretch this problem to its worst, so I suggest keeping the spreadsheet document as a working base.
targeting to "Later" to get rid of "no target" issues. Not really reasonable for 2.0.x
Reset assigne to the default "issues@openoffice.apache.org".