Bug 59635

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 backendAssignee: 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
Created attachment 73341 [details]
PDF file to reproduce the bug

While browsing a PDF document, when I scroll to the end of the first page and see the second page, the first page that I have just pass over suddenly starts being rendered as the second page. So I begin to see *two of the second pages*. This is the casae for some of my pdf files, but happens everytime when I try a problematic PDF file.

To explain the bug better, I have prepared a screencast here[1]. And after my git bisect, I have understood that guilty commit is:

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
    
    We were open-coding the functionality of map-to-image inside the source
    creation routines. so refactor to actually use map-to-image instead.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


Before this commit, everything works well. By the way I'm using evince 3.6.0-0ubuntu2 and poppler 0.20.4-0ubuntu1.1.

PDF to reproduce the bug, is attached.

Regards (and thank you very much for the Intel SNA implementation).

[1] http://bugs.launchpad.net/ubuntu/+source/evince/+bug/1101316/+attachment/3487705/+files/evincebug.mkv
Comment 1 Chris Wilson 2013-01-21 11:59:07 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.
Comment 2 Gökçen Eraslan 2013-01-21 12:11:16 UTC
(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
Comment 3 Gökçen Eraslan 2013-01-21 12:12:16 UTC
Created attachment 73373 [details]
Xorg.0.log
Comment 4 Gökçen Eraslan 2013-01-21 12:37:12 UTC
Created attachment 73374 [details]
Xorg.0.log (for Intel 2.20.19 driver)
Comment 5 Gökçen Eraslan 2013-01-21 12:38:51 UTC
I can still reproduce the bug with xf86-video-intel-2.20.19 and cairo-1.12.10.
Comment 6 Gökçen Eraslan 2013-01-21 12:43:18 UTC
Created attachment 73375 [details]
Xorg.0.log (for Intel 2.20.19 driver, UXA enabled)
Comment 7 Gökçen Eraslan 2013-01-21 12:45:28 UTC
The bug is also reproducible with UXA accelmethod, instead of SNA.
Comment 8 Chris Wilson 2013-01-23 15:12:30 UTC
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>
Comment 9 phanisvara das 2013-01-25 11:58:56 UTC
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.
Comment 10 Gökçen Eraslan 2013-01-25 14:03:05 UTC
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
Comment 11 Chris Wilson 2013-01-29 09:45:17 UTC
(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?
Comment 12 Chris Wilson 2013-02-10 13:42:33 UTC
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.