Bug 13084

Created attachment 12348 [details]
problem in GIMP 2.4

Created attachment 12349 [details]
Problem in evolution 2.12.1

Weird.  Can you use git bisect to track down which change caused it?

git-bisect gave this commit:

git bisect good
c64335a9a846ba18411a720f6e69e511b15e2c6b is first bad commit
commit c64335a9a846ba18411a720f6e69e511b15e2c6b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 17 23:12:49 2007 +0100

    [cairo-scaled-font-subsets] Simplify boolean return code.
    
    _cairo_sub_font_lookup_glyph() was returning either a NULL_POINTER
    error or success whereas its only caller was using it as a simple
    predicate and handled the 'error' rather than propagate it upwards.

:040000 040000 17e7e66b51085bcf659910493426eb714d787394 b48e56fcad5c6e9f9bb766ba79570dedec67f7a6 M      src

I'm not sure however if I correctly followed the bisection procedure. Is there a way to checkout cairo as of that commit and then the previous to verify?

This will create and switch to a new branch from the 'bad' commit:
git checkout -b b0rk c64335a9a846ba18411a720f6e69e511b15e2c6b

Then compile and test as normal.

To go back one commit, you can use
git reset --hard HEAD^

However, I can confirm the bug in master but it's not from c64335a. Instead it arises from commit 5c08226a0f7bc373a96fe75d15ad854910eb3265 - more specifically from the call to _cairo_clip_reset(). Time to understand how I managed to break the code once again...

(In reply to comment #5)
> However, I can confirm the bug in master but it's not from c64335a. Instead it
> arises from commit 5c08226a0f7bc373a96fe75d15ad854910eb3265 - more specifically
> from the call to _cairo_clip_reset(). Time to understand how I managed to break
> the code once again...

Chris,

Thanks for chasing this one down. I'm marking this bug as a "blocker"
since it's a regression that we'll need to have fixed before a 1.6
release.

I'm looking forward to a new test in the test suite for this.

Thanks again,

-Carl

(In reply to comment #6)
> I'm looking forward to a new test in the test suite for this.

Just doing that - I'm in the middle of isolating the sequence of clipping + show glyphs that gimp uses.

Okay, I've found the issue. The gimp status bar essentially does:
 cairo_reset_clip();
 cairo_new_path();
 cairo_clip();
 cairo_show_text("Background...");
which triggers _cairo_clip_set_all_clipped() and interferes with the xlib backend whilst rendering glyphs. This also triggers a new bug in the pdf backend...

Test case: commit 641215b2b018e98b298db5042360e2e22ab5a0aa
Fix: commit 2f0867b43fbc9a385a32a2a39895f4c3559f6ddf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Nov 6 09:44:03 2007 +0000

    [cairo-surface] Handle the all clipped out case.
    
    Explicitly handle a clip which represents that the entire surface is
    clipped out.
    
    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=13084.

Created attachment 12372 [details]
Evolution 2.12.1 - different problem

Hello, I've applied the patch taken from git to my local copy of cairo; while it fixes the problem with GIMP it just changes the glitch while loading evolution. See the attached screenshot.

I'm not able to reproduce the evolution glitch, do you have any other examples of broken applications?

Alternatively can you try tracing the cairo commands either using libcairowrap  [http://people.freedesktop.org/~jrmuizel/libcairowrap-0.1.tar.gz] or cairo-trace [git://annarchy.freedesktop.org/~ickle/cairo-trace]. Both use LD_PRELOAD to intercept the calls to cairo.

Created attachment 12488 [details] [review]
Revert clip->all_clipped

This patch (against head, 62d64e12) reverts the attempt to eliminate the redundant work when the context is all clipped out. I'm interested to see if this explains the few regressions seen in 1.5.2.