Apache OpenOffice (AOO) Bugzilla – Issue 106692
Anti-aliasing makes move/resize slow
Last modified: 2017-05-20 11:33:50 UTC
This issue may be related to all OpenOffice applications, but it is most annoying in Draw, up to the point that I wanted to give up on using it. Since the introduction of Anti-aliasing moving or resizing complex objects has become unreasonably slow. It seems to be unrelated to the speed of the PC. As I most often import complex drawings (pdf's converted to svg, and import the svg) the documents in Draw can contain a few thousand objects. While moving or resizing the group of objects OO freezes. Then I discovered that disabling Anti-aliasing puts everything back at the 'old' speed. It appears that Draw attempts to anti-alias *during* move or re-size actions. As it at the same attempts to show me what I'm doing (by showing the 'grayed' image during mover/re-size - which is great) this is to much for even the best machines. I vote to disable anti-aliasing during move/re-size, as it is currently beautiful but unusable during 'real' work, so needs to be disabled through <options><settings> manually. During move/re-size the 'grayed' objects do not need to be anti-aliased, the are a 'grayed' preview image anyway. Ferry
Reproducible. Reassigned.
AW: Of course AA comes to some cost, and of course it's used during interactions, else the transition would not be complete. I see Your point, but i am pretty sure there will be no majority wanting non-AAed interactions, especially when You are able to switch them off. The goal is anyways to work on speed botlenecks (varius tasks) and make graphic output faster and faster over time. I cannot accept this as a defect since it works as defined. It's also not an enhancement to go a step back. It's not a feature since the better alternative is to male interactions faster in general. BTW: Just tink about e.g. mac-users; they would stop using OOo immediately when they see a non-AAed line :-) Let's keep it open for a while (as task) and see if the community comments and/or votes for this 'task'...
I think you are missing the point here: When I try to drag (move) a group of objects it can take 10 sec for OO to responds. In the mean time it seems to freeze. I do not think this is 'defined behavior'. I guess that the responsiveness of OO is not defined in terms of time (should start dragging within 0.1 seconds) or not defined at all. Works as defined can not really be an excuse when the behavior has not been completely defined. As said: it is this slow, whether used on a dual core 1.2GHz or a 1.2GHz duron. The only way to do real work now is to disable AA completely. Which is obviously worse then during move, copy etc. Did you actually try it with complex objects? Do you need one from me? Ferry
AW->ftoth: Maybe i expressed not clear enough what i intended to tell. First, it's more than welcome that You write tasks and take part in enhancing OOo, this is greatly appreciated. In fact, with 'defined behavior' i talk about using AA consistently (also in interactions), and not about timings. You are right, timings are not really defined, but it is clear that such changes should not make the speed of interactions 'worse' in the sense of slower which would make the user's experience less enjoyable. Thus, the target is to make AA faster in that situations, but not to switch it off. We know that some stuff got slower (which i called the 'cost' of AA), and i and others already did some speedup work for places where it was not obvious from the start of AA usage, so maybe Your problem is already handled. To know that (and to evtl. set to double or to identify a new problem) it would of course be helpful when You add a bugdoc and an description what to do to reproduce the behaviour. Maybe also tell about the system You work on. Currently i do neither know what objects are slow for You nor on which system (Linux?). I hope i could make clearer now in which direction we want to solve such problems. Switching off AA for interactions would be the last option (not the first) when nothing else could be done (which is normally not the case). I hope on more information from You now which would be much appreciated.
I am using Linux and I can reproduce this issue I think. I have seen Impress presentation where moving a slide in the slide ordering view took arround 20 seconds. This makes Impress unusable. Will try to attach a bugdoc soon.
Please have a look at https://bugs.launchpad.net/openoffice/+bug/499020 for more informations.
AW->ftoth: I had a look at https://bugs.launchpad.net/openoffice/+bug/499020, but could not reporoduce with example_antialiasing_linux.odg. I can select all objects on every page and interaction starts immediately (as intended) and slide panes are updated as intended, too. Maybe there is a difference in the graphic sub-systems, but it's definitely not a general error. Please use OOo's BugTracker system to add more information. What Linux version, what HW, what OOo version?
Created attachment 68777 [details] Example drawing
I check the example on https://bugs.launchpad.net/openoffice/+bug/499020 and did not find real problems there. Instead try to work a bit with my example Silkscreen.odg. This is about 1/4 of a silkscreen (a layer of a PCB board), the original is exponentially slower. It is produced from Gerber files, printed to pdf using cups-pdf, then imported into OpenOffice. You can get roughly the same results by printing to svg, then import into OO as svg. You will notice that just picking up the group and draging (yeah in the semi-transparent mode I mean) takes about 5 seconds to respond with AA turned off. The same takes 20 seconds with AA on. Then drop the object, go get some coffee and wait for OO to respond again. I kid you not. The group consists of 7619 element, which may seem much, but how fast can you count when you've got 4 cores running at 2GHz. And the original pdf had no problems even though it's size was 8MB. Ferry
AW->ftoth: Thanks for the example, i can see the problem now. What a bad import quality, BTW. Dragging the group tace roughly 3sec on my 2.6Ghz system, dropping is about 6sec. With AA off, it's roghly about the same, thus it's not the AA but the shear amount of objects. BTW: 4 cores is of no use currently; we are on changing as much and fast as we can, but currently OOo still uses a single core in most cases; a known problem coming from the old codebase. The original PDF having no problems will mostly come from PDF not needing to edit it and thus not needing to clone objects for the interaction visualisation. The expensive part seems clearly not to be AA here but the core handling and the interaction preparations and change applyings at interaction end. Your measurement of 20sec/5sec with/without AA shows that there is also still potential with AA visualisation on Your system; we are preparing faster trapezoid decomposition for polygons already (XRender can only paint triangles, triangle strips and trapezoids AAed). I will keep this task to see if/how far this will help. We are also working on the (rather old) internal model, but i cannot promise too much. Changing back owner.
On Kubuntu Karmic with OO 3.1.1 grbabing the object will take 30 seconds (AA on is 6x slower). The same thing on Debian Squeeze with OO 3.2.0 will take 3 seconds (AA), With AA off less then 0.5 seconds (6x slower). It appears major improvement happened in OO 3.2. Good news. But still AA is 6x slower, which you will notice on large or complex drawings. The original question was: can we turn off AA on drags to improve speed. Want to try with the original drawing now? There are about 30000 elements in the original. And it get's exponentially slower. Yes that's a lot. Inkscape does it, but then I need to import svg into OO, which is still problamatic.. Ferry
I don't experience this slowness problem anymore on Kubuntu Lucid.
.
Reset assigne to the default "issues@openoffice.apache.org".