Bug 13084 - cairo 1.5.2 causes font problems in GIMP 2.4 status bar and evolution 2.12.1
cairo 1.5.2 causes font problems in GIMP 2.4 status bar and evolution 2.12.1
Status: RESOLVED FIXED
Product: cairo
Classification: Unclassified
Component: general
1.5.2
x86 (IA32) Linux (All)
: medium blocker
Assigned To: Carl Worth
cairo-bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-04 14:27 UTC by Giacomo Perale
Modified: 2007-11-12 15:35 UTC (History)
0 users

See Also:


Attachments
problem in GIMP 2.4 (13.17 KB, image/png)
2007-11-04 14:28 UTC, Giacomo Perale
Details
Problem in evolution 2.12.1 (204.63 KB, image/png)
2007-11-04 14:29 UTC, Giacomo Perale
Details
Evolution 2.12.1 - different problem (65.28 KB, image/png)
2007-11-06 08:02 UTC, Giacomo Perale
Details
Revert clip->all_clipped (10.46 KB, patch)
2007-11-12 15:35 UTC, Chris Wilson
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Giacomo Perale 2007-11-04 14:27:47 UTC
cairo 1.5.2 causes font glitches in the gimp 2.4 status bar. The black antialiased text is replaced by white text. Screenshot follows.

It also causes another font-related glitch which could or could not be related, in the message view of evolution 2.12.1. When the program is launched, for a split second the message summaries collapse to the left, then the window's painting ends and everything becomes normal again. Screenshot follows.
Comment 1 Giacomo Perale 2007-11-04 14:28:26 UTC
Created attachment 12348 [details]
problem in GIMP 2.4
Comment 2 Giacomo Perale 2007-11-04 14:29:02 UTC
Created attachment 12349 [details]
Problem in evolution 2.12.1
Comment 3 Behdad Esfahbod 2007-11-05 09:42:36 UTC
Weird.  Can you use git bisect to track down which change caused it?
Comment 4 Giacomo Perale 2007-11-05 11:06:32 UTC
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?
Comment 5 Chris Wilson 2007-11-05 11:30:07 UTC
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...
Comment 6 Carl Worth 2007-11-05 13:30:04 UTC
(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
Comment 7 Chris Wilson 2007-11-05 13:32:32 UTC
(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.
Comment 8 Chris Wilson 2007-11-05 14:55:22 UTC
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...
Comment 9 Chris Wilson 2007-11-06 07:33:50 UTC
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.
Comment 10 Giacomo Perale 2007-11-06 08:02:41 UTC
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.
Comment 11 Chris Wilson 2007-11-06 08:30:00 UTC
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.
Comment 12 Chris Wilson 2007-11-12 15:35:31 UTC
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.