Created attachment 108968 [details]
Example presentation with grid enabled
With the attached presentation on a 120% zoom I see a fine grid for positioning (Disable via View - Grid - Display Grid). If it's switched on, scrolling is very sluggish. Same happens even without a grid in OOo 3.2.1 when moving a selected object, because the selection frame consists of many small diagonal lines. This is much better since LO 4.2, as it just draws a solid border (see attached PNGs).
The tests were done using LibreOffice 4.3.1 and OpenOffice.org 3.2.1 on Ubuntu 14.10 with oibaf repository:
libdrm2 - 2.4.58+git1411031830.00847f
mesa - 10.4~git1411050730.9e2473
xserver-xorg-video-radeon - 1:7.5.99+git1411032004.7c7b38
xserver-xorg-core - 2:1.16.0-1ubuntu1
linux-image-3.16.0-24-generic - 3.16.0-24.32
For the tests radeon was compiled with "#define RADEON_TRACE_FALL 1", which resulted in several of the following line:
EVERGREENCheckComposite: Component alpha not supported with source alpha and source value blending.
In an other test I also saw some of the following lines, but these don't seem related:
EVERGREENCheckCompositeTexture: Unsupported picture format 0x1011000
Hardware is a dual screen setup on a
Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] (1002:6779)
Using the on-board Intel graphics, scrolling is fine.
As a workaround I set "EXAPixmaps" to "off", which basically disables most of the EXA HW Accel
It was mentioned on IRC by glennk and agd5f, that this might be the result of a SW fallback, which forces some buffer syncs via RAM and VRAM. Intel is fine, because it uses UMA.
Created attachment 108969 [details]
Screenshot of LO Impress 4.3.2 with selection.
Created attachment 108970 [details]
Screenshot of OOo Impress 3.2.1 with selection.
Just as an other datapoint: same happens on Ubuntu 10.04 with Oneiric HWE (not really an HWE but our backport) and OpenOffice.org 3.2.1:
libdrm2 - 2.4.28-0~lhm1
linux-image-3.0.0-16-generic - 3.0.0-16.29~lucid1lhm1
xserver-xorg-core - 2:1.7.6-2ubuntu7.10
xserver-xorg-video-radeon - 1:6.14.99~git20111219.aacbd629-0ubuntu2~lhm2
mesa - 7.11.2-0~lhm1
AFAIK there was an fglrx version available for the HW (2:8.881-0ubuntu4.1~lhm1) and Xorg server, which might not show the problem - didn't test.
(In reply to Jan-Marek Glogowski from comment #0)
> EVERGREENCheckComposite: Component alpha not supported with source alpha and
> source value blending.
This is harmless. The driver doesn't support dual-source blending for sub-pixel AA text, but EXA falls back to a two-pass acceleration method which is hardly slower.
> In an other test I also saw some of the following lines, but these don't
> seem related:
> EVERGREENCheckCompositeTexture: Unsupported picture format 0x1011000
Actually, I think this is the problem. There is no acceleration for 1bpp bitmaps.
At one point, you mentioned on IRC that the problem seems less severe with driver version 7.2 than with 7.3. Is that still the case, or was it just because of different zoom factors? In the former case, it would be interesting if you could bisect which change between 7.2 and 7.3 made it worse.
Other than that, I'm afraid there's very little chance that this will ever be fixed with EXA. If glamor from current xserver Git master still shows the same problem, please file a bug report against glamor, and hopefully someone will implement acceleration for the affected paths in glamor at some point.
I dist-upgraded my system and got new packages:
libreoffice - 1:4.3.3-0ubuntu1
mesa - 10.4~git1411060730.cd745d~gd~u
intel - 2:2.99.916+git1411060731.0532a3~gd~u
and I don't see any fallback messages - neither with LO nor OOo.
I updated my patch to actually list enabled traceing in the Xorg.log and I get
[ 1334.318] (II) RADEON(0): Compiled with EXA fallback tracing
in the Xorg.0.log so it seems the patch is fine.
What I actually never checked, if the scrolling really added the original fallback lines and my feeling told me these were too few.
I also tested with "AccelMethod" "glamor", which didn't help.
Created attachment 109017 [details] [review]
Log enabled fallback and draw trace compile options
I just tested Intel only again and it's fine.
I see a lot of entries like:
[ 236.480] reporting 7 6 17 128
probably because I tried to use radeon as a 2nd monitor. But this setup is currently completely broken. The radeon attached monitor just shows various small stripes of different colors and even the intel monitor has various graphic glitches, including a jumping cursor without even moving the mouse (it was jumping in a larger triangle in one quater of the screen!). Just removing the radeons monitor fixed intel - oh well.
(In reply to Jan-Marek Glogowski from comment #5)
> What I actually never checked, if the scrolling really added the original
> fallback lines and my feeling told me these were too few.
Right, it's possible that EXA falls back to software for the dotted lines before the driver even gets a chance to say anything about them.