Issue 106692 - Anti-aliasing makes move/resize slow
Summary: Anti-aliasing makes move/resize slow
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: OOo 3.1.1
Hardware: All Linux, all
: P3 Trivial with 2 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2009-11-06 22:44 UTC by ftoth
Modified: 2017-05-20 11:33 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---

Example drawing (77.62 KB, text/plain)
2010-04-06 13:56 UTC, ftoth
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ftoth 2009-11-06 22:44:55 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'

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.

Comment 1 wolframgarten 2009-11-09 08:14:59 UTC
Reproducible. Reassigned.
Comment 2 Armin Le Grand 2009-11-10 10:51:47 UTC
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'...
Comment 3 ftoth 2009-11-10 17:21:34 UTC
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?

Comment 4 Armin Le Grand 2009-11-11 10:36:42 UTC
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.
Comment 5 fmms 2009-11-17 01:38:49 UTC
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.
Comment 6 p92 2009-12-21 13:18:29 UTC
Please have a look at 
for more informations.
Comment 7 Armin Le Grand 2010-04-06 11:19:22 UTC
AW->ftoth: I had a look at,
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?
Comment 8 ftoth 2010-04-06 13:56:14 UTC
Created attachment 68777 [details]
Example drawing
Comment 9 ftoth 2010-04-06 14:08:45 UTC
I check the example on 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.

Comment 10 Armin Le Grand 2010-04-06 16:09:47 UTC
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.
Comment 11 ftoth 2010-04-07 08:01:55 UTC
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..

Comment 12 p92 2010-05-20 12:14:23 UTC
I don't experience this slowness problem anymore on Kubuntu Lucid.
Comment 13 cno 2010-06-09 22:35:51 UTC
Comment 14 Marcus 2017-05-20 11:33:50 UTC
Reset assigne to the default "".