Created attachment 58879 [details] Example presentation Moving or resizing text boxes is very slow in Impress when image antialiasing is enabled. I thought this old bug was already reported but it seems not. However, I'm not an Ubuntu user but I saw a bug report (https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/411542) that deals with the same issue. To reproduce : open the attached presentation example, and, with image antialiasing enabled in the LibreOffice options, try to move or resize the box which contains the text "Example (slow)". This operation is very slow even on a fast machine. If you disable image antialiasing in the LibreOffice options then the move / resize operation becomes very fast and usable. I also discovered that reducing the box size around the text greatly improves the speed (with antialiasing enabled). This can be checked on the example by moving the box which contains the text "Example (fast)". The bug appears (at least) on LibreOffice 3.4.3 and 3.5.1, on Linux (Official build with deb packages on Debian Squeeze) or Windows XP SP3 (Official build). And since I have two computers with ATI and Nvidia graphic cards, it seems to be independent of the hardware.
Confirmed by 28 affected users downstream on launchpad.
I first became aware of this bug on LibreOffice 3.5.6 (official Arch Linux build) on two separate computers. I also confirm the issue persists with LibreOffice 3.6.1 on Arch Linux. Disabling anti-aliasing for graphics output significantly improves move/resize performance for text and graphics boxes. With anti-aliasing enabled, move/resize is laggy and painfully slow as reported numerous times on Launchpad. The machines I tested this on both have Intel GM45 chipsets (Core 2 with GMA graphics) with Intel xf86 drivers versions 2.20.0 through 2.20.6. Since Roland reported the issue for both AMD and NVIDIA graphics, I assume this is not graphics drivers related.
Created attachment 75800 [details] Glitches during move
Same for me, but on one computer I've glitch during the move, and sometimes persist after. Perhaps drawing these lines is the problem Seems Drawing is better on this than text box from Impress (not exactly same border during move).
The problem persists in LO 4.1.0.0.beta1 in Ubuntu 13.04 64-bit in a fairly modern hardware (i7, 8GB RAM). I don't see a significant improvement after disabling AA (In Tools > Options > View > Screen font antialiasing). Reducing the size of the box containing the text does improve a lot the speed. In my opinion, this should be labeled as a high important bug as it creates a very bad impression on people using LO for the first time.
(In reply to comment #5) > I don't see a significant improvement after disabling AA (In Tools > Options > > View > Screen font antialiasing). > It's the other anti-aliasing, the one under "Graphics output" on the same tabpage.
*** Bug 63439 has been marked as a duplicate of this bug. ***
With 28 users over on launchpad + the report here and dupe, upping to Major - High.
I am experiencing similar issues when working with graphics in LibreOffice Writer. If anti-aliasing is turned on, moving graphics becomes very sluggish and unresponsive. (observed on LO 3.6.6)
Hi, I can't reproduce with 4.1.2.3 under Ubuntu 13.10 (64-bit).
I can reproduce this bug with 4.1.3.2 running on 64-bit Linux Mint 15 (i.e. Ubuntu 13.04). Turning anti-aliasing off resolves the issue completely.
*** Bug 70914 has been marked as a duplicate of this bug. ***
I can reproduce what is described in bug report 70914, i.e. there is almost no lag when two text fields are selected, even with anti-aliasing turned on. The lag disappeared for me as well when the text field was moved far from its original position. With 4.1.3.2, 64-bit Linux Mint 15
I confirm turning off image antialiasing fixes this. Wow - it is awesome! Thanks, now it works like a charm.
This issue is FIXED in LibreOffice 4.2.1.1 RC (can someone please confirm this?). Thank you guys for your great work!
Since I was affected by this bug before and now can't reproduce it anymore in LO 4.2.3.2 RC, I mark this bug as FIXED. Please feel free to reopen it, in case you still encounter this bug in a recent LO installation.