| Summary: | Scrolling in LibreOffice Impress with enabled grid is very sluggish (EXA) | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Jan-Marek Glogowski <glogow> |
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
| Status: | NEW --- | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
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'm puzzled. 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.