Apache OpenOffice (AOO) Bugzilla – Issue 110384
Extremely slow scrolling in calc when charts are displayed
Last modified: 2022-10-28 12:54:21 UTC
Displaying / scrolling any chart in a calc spreadsheet maxes processor and takes a very long time. Very slow redraws result in extremely slow scrolling. A simple chart takes approximately 2-3s to redraw completely, and scrolling down a page with several charts will "grey out" calc for 2-10s. We use several PCs running Ubuntu 9.10(i386), Ooo310m19. 2.6GHz - 3GHz Intel Core2 Duo/Quad processors. Nvidia, Ati & Intel GM45 graphics. Two PCs Win XP, ooo310m19. All these PCs exhibit the same problem. One PC running ooo300m15 on Ubuntu 9.04 has this issue (or very similar) to a much lesser degree. Processor maxes at 30%, slow chart display/scroll but not enough to make work cumbersome. Seems to be exactly the same problem as: Debian Bug report logs - #464856 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464856
Please attach a test document. Are you using version from ubuntu distribution or official version?
Created attachment 68636 [details] test file exhibiting slow chart scrolls. Pls see "Grafer" tab
We are currently using the Ubuntu distributed versions on most computers. I have however installed the latest official version downloaded from your site on one of our most used laptop types (Dell Vostro 1015, I-Core2Duo 2.2Mhz, 2Gb Ram). The results are the same as previously described.
Reproducible on ubuntu 9.10, DEV300m75. Slow scrolling, high CPU usage. [dell latitude d820, T2500 @ 2.00GHz, 2,5 GB RAM, nVidia Quadro NVS 110M/GeForce Go 7300]
The PC mentioned in my earlier post running ooo300m15 on Ubuntu 9.04 that was more or less ok has now been upgraded to Ubuntu 10.04 and ooo320m12 (ubuntu version). This PC now exhibits the same problem to full extent rendering calc virtually useless on larger files with charts. I am getting a lot of grief from my users in regards to this issue (I convinced them to go over to Ooo). Pls let me know if there is any solution in the pipe. I know this is not a solution but perhaps something like not updating the charts until the scroll action is completed could be implemented? IE on scrollbar movement: no chart redraw until mouse button is released, and no chart redraw until mouse scroll-wheel has stopped for x ms. I think this could perhaps help alleviate the problem.
@aw, is there a way to speed up the rendering of metafiles containing polygons with many many points?
AW->IHA: Polygon output now goes pretty direct to the sub-system, e.g. on WIN32 to GDI+, so this is very system-dependent. For fat lines (that's the most time consuming part) we added some faster and more direct trapezoid decomposer which is needed for AAed rendering. HDU can tell in which version this is used now, i am currently not sure. Setting HDU on cc. Just did a fast profiling on WIN32, most time is spent inside the GDI+ methods (in the OS).
IHA->AW: Does that mean - no the rendering cannot be fastened? If so please consider whether a multithreaded asynchron preparation of the metafiles is possible. If you think that nothing can be done here please close the issue as cannot fix. If you think there are chances for enhancement please assign the issue to that one who can do them. The chart itself has nothing to do with the metafile rendering, so I am the wrong owner. Thanks!
AW->IHA: You asked a question and i answered it. I saw no mention to take over and OTOH we will need HDU's answer, too. >If so please consider whether a multithreaded asynchron preparation of the >metafiles is possible. The Metafile is already only once decomposed to primitives and those are already buffered. Thus, at repaint, that data goes pretty direct to the system-level rendering (VCL), as i already described. Since VCL is not multi-thread safe itself, multithreading is no option unless VCL is changed to work with that (an old known problem with solarmutex). >If you think there are chances for enhancement please assign the issue to that >one who can do them. The chart itself has nothing to do with the metafile >rendering, so I am the wrong owner. It would also be possible inside the chart to reduce the data points in a useful manner (as AFAIK is done already for some chart types). Maybe, our big competitor is doing something like this? So there are of course also optimization methods within the chart itself from my POV. AW->IHA: Please add information how many points those fat lined polygons exist of. AW->HDU: Please add information when the new trapezoid decomposer is in action. To not make anyone feel bad, I'll just keep the task for now. Usually it goes to the one who is to add information, but who cares...
@iha,@aw: please test with CWS vcl111: there the very expensive (because uncached) call to check for self intersections can be avoided because the new intersection-tolerant tesselator is used
AW: Thanks HDU. When will vcl111 be integrated? AW: Also a good read: #i98907# shows what is already done and how much speed improvements are already done (see measurements at the end). Together with #i111021# which is mostly for Linux/Solaris the 3.3 should solve the problem.
AW: Investigated the idea of nixvitae to break the repaint when scrolling again. I already tried to do something like that once. Problem is that VCL is not multithreaded and there is no way to break the current paint when a change happened. I tried to add a 'break'-flag for all paint and to stop AFAP when set, but then method to react on inputs (AnyInput()) is not fine granular enough to implement something like this. I also compared locally fat line painting outside chart: Created an impress doc with 3 lines a 5580 points. Speed is comparable with chart display. I also again ensured that just GDI+ is called as direct as possible. It is...
Hi Everyone, I suffer with this behavior since a long ago. Both on linux, x86-64 (OpenSuSE, Go-OO derived and now Libò and vanilla linux x86-64 to help testing 3.3) and Windows. I just retest OOo 3.3, rc8, vanilla, linux x86-64 with my calc-with-graph file and this issue's file and these are the results: - with my multisheet Calc file (that I immediately attach) I must wait about 10 s to view one of last two graph sheets, xorg process gain 98% cpu for some seconds both in viewing graph sheet or scrolling it (each time), then cpu come back down and OOo is pretty usable; - with this issue Calc file I saw the two graphs after about one minute but OOo still remains occupied (cpu level at about 100%) and I must close (not kill) it. I think this behavior must be faced up. We have to deal with it to get more professional use of the very important OOo (and derived) part that is Calc with its functions and capabilities. Isn't it? Carlo
Created attachment 75356 [details] Multisheet Calc file with last two sheet with graphs suffering high cpu rendering in both viewing and scrolling
Two last considerations: - I just attach my ods file saved with vanilla OOo 3.3rc8 whose size is 736.9 kByte, but the 7z version is 158.8 kByte (only!!!); this surprised me because ods is also a compressed (zipped) file but I did't expect a similar difference in sizes. 7zipping the first issue file with the same system yields two similar sizes: ods file size is 1.1 MByte, 7zipped one is 926.7 kByte. What do you think about? - I think objects (graphs, non bitmap graphics file format, ...) cacheing (with the bitmap rendered version) is a good first way, but I ask myself because first render time is so high (too high!!!) and so what is wrong in some architectural choices. I think demanding to OS graph part the object rendering is a correct way but with this performance there is clearly something that escape and slip out to us. Is there someone (e.g. like someone of the Blender/FreeCad/Brl-Cad/Pov-Ray/... teams) that could help us first fixing and then re-engineering this subsystem? Carlo
Some test on a Mac to your information: I'm using MacOS X 10.6 on a nearly five years old 1,83 GHz Intel Core Duo MacBook pro Openig the document and holding "scroll down"-arrow with the mouse OOo 3.2.1 scrolls tolerable nice (19 sec. for all full scroll of the document) OOo 3.3.rc8 is really slower (30 sec. or all full scroll of the document) LibreOffice 3.3.rc1 has most problems with that (35 sec. or all full scroll of the document)
AW: Thanks for the new inputs. Please also read the old findings above; slowdowns are the cost for AntiAliasing improvements. Those do not come for free unfortunately but need more rendering time - not in OOo, but in the system-dependent graphic systems, e.g. on WIN GDI+ which AAed is simply slower than not-AAed. If You do not need AAed output, You may switch it off in tools/options/view and see old speed of non-AAed versions of OOo return, but pixeled. You cannot have the money and the choccolate :-( For Unix/Linux OTOH there is XRender and it's ability to only render trapezoids or triangles if AA is wanted. This means that for those systems a triangulation/trapezoidation is needed which is in place and pretty fast already. We are constantly working on this (various tasks already), but AAed graphic will never get the speed of non-AAed with the same amount of graphic data to be rendered. I still think for big charts a reduction of data depending on the resolution to visualize would be an option, too.
AW->uwealtmann: For the difference between OOo 3.2.1 (19 sec.) and OOo 3.3.rc8 (30 sec.) i have no idea right now; i will take a look what has changed in the Mac version. Since there were no changes in Drawinglayer, maybe the rendering layer for MacOS has changed somehow here...
AW->PL: Unfortunately i have no Mac to evaluate this. Cold You please take a look and evaluate the difference between OOo 3.2.1 and OOo 3.3, maybe on Mac fat AAed lines are not yet painted optimal. Those lines go directly from primitives to VCL using system rendering (see desc10).
.
I just tried 2 reproduce on debian squeeze with kde4 and opengl (debian OO 3.2.1-11). Generating the graphs takes about 2 sec with AA on by dual core 3GHz. Tried to export to xls and view with Excel (under wine) but the indirect addressing used doesn't seem to work in Excel. Another bug? Unfortunately I can not compare now. But would not be surprised is MS caches the bitmap after rendering. Ferry
AW->ftoth: Thanks for checking this out. It would be nice if you (or anyone else listening) could get the Excel comparison to work, or do at least some charting there with the same amount of data and size. Bitmap caching is not really an option here; OOo intends to run on small systems, too, and with the sizes of bitmaps we are talking here about we try to avoid things like that. Let a Sheet have some of this charts (not even complex) and memory explodes. We already had some iterations of tasks from people whom the footprint is too big, and they have valid reasons. I am still wondering about system draw performance; as stated above (and checked in debugging) the geometry (fat lines here) is pretty directly dumped to GDI+ (in Windoes case), so it's not the architecture of the OOo graphic subsystem in general. A problem still is that there is no way with VCL today to check if the view has changed again during paint and break it cleanly. Multithreading support could also help, but currently will not work with VCL, too.
Hi Everyone, I was thinking over, reflecting on, the various OS modules to which you (we) are demanding the sheet rendering (anti aliasing and so on)... Are we so sure that the current chosen modules (GDI+, XRender, Drawinglayer) are the one the OSes now (!) are powered to do these kind of tasks??? May be that the chosen modules are obsolete (at all or at least for these kind of tasks) and maintained by the various OSes only for retro-compatibility? I ask myself this question because I have in mind that in the 3D graphics we frequently deal with 30 or 40 fps (frames per second!!!) and here we are on the contrary speaking of 1 frame in 20 or more seconds and so 1/20 fps that is 0,05 fps...!!! Is this caused only for the pour 2D performance with respect to the richest 3D one or are the chosen modules obsolete as supposed by me? Do you think there are something that sound wrong? And this is not the sound card nor pulse audio! ;-) Carlo
... may be the correct ones are: DirectX, OpenGL, OpenGL instead of GDI+, XRender, Drawinglayer ? What do you think about?
AW: I really wish it would be soo easy :-( DirectX and OpenGL are 3D renderers, which: (a) cannot paint offscreen (b) do not AA at all basically (c) do not paint PolyPolygons, nor fat lines (a) means that You only can paint to screen directly and accept a return of flickering screen contents. Currently the repaint goes into a offscreen surface and gets copied to the front to avoid flickering, thus only renderers which can render to offscreen surfaces are usable. Second possibility is switching two contents (e.g. of a window). Problem here is that the whole OOo window IS a system window, the UI elements around the paint surface (toolbars, side panes, ...) are no system windows, but VCL (virtual) windows which would be overpainted. In both cases, the whole VCL and apps need to be adapted/rewritten to be flipped completely/to not paint in regions of VCL windows. (a) also means You have no way for printing; the resolutions would be so huge in print output preparation that you would need another method of preparation for that (2nd renderer). This also needs renderers which can work offscreen, if bitmap preparation for printing is needed (e.g. the case for transparent parts in objects). (b) means that you would need some e.g. 4x4 oversampling; besides the video mem needed (remember OOo is also for small devices and older machines) You never get the full 256-step-AAed view 2D renderers can do. A quality loss. (c) means that You would have to generate the filled polygon geometry for the fat lines and triangulate them. This means (esp. in the examples) megabytes of data You need to buffer if you want fast repaints. Also triangulation (despite we have it) is not cheap at all. Believe me, currently what we use is pretty much the best you can use. Without a complete rewrite (or a very huge adaption) of OOo with those concepts in mind, this cannot be done (unfortunately). You may try it out, it's open source. The better way would be to make VCL thread-save and being able to stop the current paint when the user scrolls (kinda lazy-repainting of complicated regions). This is also a huge task (people tried to make VCL reentrant and thrad-safe for some years already), but it's more doable than using 3D renderers. Sorry for the bad news, but it's more complicated than a first look may show...
Thank you aw, I believe and trust in you! ;-)
CL: Some small corrections. While AW is right with his conclusion, DirectX and OpenGL (a) can paint offscreen (b) support AA (c) could paint PolyPolygons and fat lines using Shaders But all this comes at a cost and printing is the main reason why we still need a fast and quality software renderer. For printing it would be so much easer if there was an accepted standard cross platform vector format like PDF on the Macs. One short term solution for Windows platforms only would be to replace gdi+ with direct draw (*) which is the new Windows 7 only rendering API for vector graphics. GDI+ is dead slow so at least for Windows 7 users this should ease the pain with not a lot of work. Has any one compared the rendering speed on mac? I'm curious how the Quartz rendering compares to XRender and GDI+ (*) direct draw is not the 2d rendering api available in old Direct X versions, its a new interface introduced by microsoft for Windows 7
I notice that movement of charts is slower in OOo3.3 than in OOo3.2. This is independent of the settings for antialiasing. It is not impossible to move the chart, but it makes no fun to wait two seconds till the graphic is on its new place. Refresh of the screen while scrolling is affected too. A smooth scrolling with the slider is not possible in the new OOo3.3 version.
"alg" committed SVN revision 1480935 into trunk: i110384 added better fat line rendering where possible
ALG: Added better FatLine drawing where we have something already in VCL, this makes things much better already. Still no smooth scrolling, but a refresh of (at my local conditions) 4s compared to 25s before, not that bad. More is possible, but will need system-dependent renderers.
adjusted target to version that will contain the fix