Summary: | Cairo 1.12.10 causes evince to misrender pages of a PDF file while scrolling down in continuous mode [BISECT] | ||
---|---|---|---|
Product: | cairo | Reporter: | Gökçen Eraslan <gokcen.eraslan> |
Component: | xlib backend | Assignee: | Chris Wilson <chris> |
Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | major | ||
Priority: | medium | ||
Version: | 1.12.8 | ||
Hardware: | Other | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
PDF file to reproduce the bug
Xorg.0.log Xorg.0.log (for Intel 2.20.19 driver) Xorg.0.log (for Intel 2.20.19 driver, UXA enabled) |
Description
Gökçen Eraslan
2013-01-20 19:11:20 UTC
I didn't see the issue scrolling in evince with the mouse, keyboard or scrollbar. This could either be a cairo bug or a driver bug, so please can you also update your drivers, attach an Xorg.log and describe your desktop environment. (In reply to comment #1) > I didn't see the issue scrolling in evince with the mouse, keyboard or > scrollbar. This could either be a cairo bug or a driver bug, so please can > you also update your drivers, attach an Xorg.log and describe your desktop > environment. I'm using latest Intel DDX driver and Xorg server from the Xorg edgers[1] Ubuntu PPA, with SNA acceleration. Intel DDX package is xserver-xorg-video-intel 2:2.20.17+git20130110.8a8edfe4-0ubuntu0sarvatt~quantal My desktop environment is Unity in Ubuntu 12.10 and I'm attaching Xorg log right now. [1] https://launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=quantal Created attachment 73373 [details]
Xorg.0.log
Created attachment 73374 [details]
Xorg.0.log (for Intel 2.20.19 driver)
I can still reproduce the bug with xf86-video-intel-2.20.19 and cairo-1.12.10. Created attachment 73375 [details]
Xorg.0.log (for Intel 2.20.19 driver, UXA enabled)
The bug is also reproducible with UXA accelmethod, instead of SNA. commit fa4f48cccb6c7f4e1afb2ff4b98b906b7d8d4afc Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 23 15:04:26 2013 +0000 xlib: Do not upload the whole image just because we want an entire row Fixes regression exposed by commit a73e7ff0186176bc82cd3ae1432c054c1fd3aebd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jan 6 11:29:27 2013 +0000 xlib: Simplify source creation by use of map-to-image but ultimately from commit 74941f822015cc50cd8477d0cf97f1a70dbff60b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 2 22:27:55 2013 +0000 xlib: Use SHM transport for ordinary image uploads Reported-by: Gökçen Eraslan <gokcen.eraslan@gmail.com> Reported-by: Guillaume Ayoub <guillaume.ayoub@kozea.fr> Reported-by: Emmanuel Benisty <benisty.e@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59635 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> i believe that this is the same regression that causes GIMP to mess up zoomed images and display artefacts when using tools on an image. before the release of this last patch, archlinux developers released a patched version of cairo that removed those two commits and got rid of the regression. now you released this patch, but the "fixed" new package re-introduces the regressions, at least in GIMP (don't have evince installed). here's the link to the arch bug tracker dealing with this: https://bugs.archlinux.org/task/33463 -- phani. Can you test my test PDF file to reproduce this[1] using evince? Because, latest cairo fixes my PDF rendering issues on xf86-video-intel-2.20.19 (what is your driver by the way?). Then, we may have a clue about whether this is a driver issue or not. [1] https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1101316/+attachment/3487705/+files/evincebug.mkv (In reply to comment #9) > i believe that this is the same regression that causes GIMP to mess up > zoomed images and display artefacts when using tools on an image. I worked through a very similar problem with Mitch that was exposed on the GIMP master branch (but not in 2.8): commit c006b886d28a772d7a62cec52ab7e0c8196c36f6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 29 03:01:31 2013 +0000 xlib/shm: Force synchronisation for scratch SHM image buffers The scratch image buffers are used for uploads to the xserver and so we must be careful not to overwrite active SHM segments. Unfortunately we told the core SHM allocator that we would sync before using the images, which was a lie. Reported-by: Michael Natterer <mitch@gimp.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Can you please test if that resolves your issue? I believe I fixed this in cairo-1.12.12 |
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.