Bug 5200 - Incorrect text rendering when in x86 64-bit precision mode
Incorrect text rendering when in x86 64-bit precision mode
Status: RESOLVED FIXED
Product: cairo
Classification: Unclassified
Component: general
1.0.2
x86 (IA32) Linux (All)
: high major
Assigned To: Carl Worth
cairo-bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-30 15:47 UTC by Billy Biggs
Modified: 2006-04-12 14:32 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
bad.png (2.57 KB, image/png)
2005-11-30 15:50 UTC, Billy Biggs
Details
good.png (2.56 KB, image/png)
2005-11-30 15:51 UTC, Billy Biggs
Details
gdk patch (1.87 KB, patch)
2006-02-18 06:16 UTC, Behdad Esfahbod
Details | Splinter Review
test case (2.97 KB, text/plain)
2006-04-07 08:20 UTC, Felipe Heidrich
Details
failing scenario (3.79 KB, image/png)
2006-04-07 08:23 UTC, Felipe Heidrich
Details
working scenario (3.73 KB, image/png)
2006-04-07 08:24 UTC, Felipe Heidrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Billy Biggs 2005-11-30 15:47:58 UTC
The Java virtual machines from Sun and IBM put the FPU into 64-bit mode rather
than Linux's default 80-bit mode.  For a little background on this, see:

  http://www.srware.com/linux_numerics.txt

When in this mode, a bunch of weird rendering issues appear in text of GTK+ 2.8
applications.  The easiest way to see this is to watch the underlined characters
in menus.  The GTK+ application below reproduces the problem when using a font
of "Arial 9" at 96-DPI.  This bug should also occur under other OSs that use
64-bit precision by default, such as FreeBSD, on other architectures such as
PPC, and probably also when compiling cairo using -mfp-math=sse.  However, I
have not verified any of those configurations.

#include <string.h>
#include <gtk/gtk.h>
#include <fpu_control.h>

int main (int argc, char **argv)
{
    GtkWidget *window, *menu, *vbox, *item, *bar;
    fpu_control_t fpu_control;

    _FPU_GETCW (fpu_control);
    fpu_control &= ~_FPU_EXTENDED;
    fpu_control |= _FPU_DOUBLE;
    _FPU_SETCW (fpu_control);

    gtk_init (&argc, &argv);
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    g_signal_connect (G_OBJECT (window), "destroy",
                      G_CALLBACK (gtk_main_quit), NULL);
    vbox = gtk_vbox_new (0, FALSE);
    gtk_container_add (GTK_CONTAINER (window), vbox);
    bar = gtk_menu_bar_new ();
    gtk_box_pack_start (GTK_BOX (vbox), bar, FALSE, FALSE, 0);
    item = gtk_menu_item_new_with_mnemonic ("_File");
    gtk_menu_shell_insert (GTK_MENU_SHELL (bar), item, 0);
    menu = gtk_menu_new ();
    gtk_menu_item_set_submenu (GTK_MENU_ITEM (item), menu);
    item = gtk_menu_item_new_with_mnemonic ("Open _Type...");
    gtk_container_add (GTK_CONTAINER (menu), item);
    item = gtk_menu_item_new_with_mnemonic ("Open Reso_urce...");
    gtk_container_add (GTK_CONTAINER (menu), item);
    item = gtk_menu_item_new_with_mnemonic ("Sho_w In");
    gtk_container_add (GTK_CONTAINER (menu), item);
    item = gtk_menu_item_new_with_mnemonic ("Ne_xt");
    gtk_container_add (GTK_CONTAINER (menu), item);
    item = gtk_menu_item_new_with_mnemonic ("Pre_vious");
    gtk_container_add (GTK_CONTAINER (menu), item);
    gtk_widget_show_all (window);
    gtk_main ();
    return 0;
}

This problem is not reproducable under GTK+ 2.6 and it smells a lot like a cairo
problem.
Comment 1 Billy Biggs 2005-11-30 15:50:53 UTC
Created attachment 3949 [details]
bad.png
Comment 2 Billy Biggs 2005-11-30 15:51:09 UTC
Created attachment 3950 [details]
good.png
Comment 3 Behdad Esfahbod 2005-12-01 02:48:54 UTC
Billy, is it the bug reported here:

  http://bugzilla.gnome.org/show_bug.cgi?id=307196

I hope it is.  Anyway, can you check the patch attached in there?
You reproduce this only on 86_64?
Comment 4 Billy Biggs 2005-12-01 03:03:54 UTC
I'll try out the patch.  Note that this is on x86 not x86-64.
Comment 5 Douglas Pollock 2006-02-18 02:44:42 UTC
See also downstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=123425.      
In particular, the screenshot attached.  If this is really the problem, then I   
feel this should be upgraded to major (feel free to disagree <g>).   
   
I've tried the patch in http://bugzilla.gnome.org/show_bug.cgi?id=307196  
against GTK+ 2.8.8, using Cairo 1.0.2.  I still see the problem described in  
https://bugs.eclipse.org/bugs/show_bug.cgi?id=123425.  
  
Can you think of a workaround?  We would rather not ship Eclipse 3.2 with this 
still broken.... 
 
Comment 6 Owen Taylor 2006-02-18 03:06:15 UTC
This bug hasn't even been tracked down to Pango or Cairo ... how could
we suggest a workaround? I'd suggest that actually debugging the problem
would help move the process along...
Comment 7 Douglas Pollock 2006-02-18 04:59:35 UTC
(In reply to comment #6)        
> This bug hasn't even been tracked down to Pango or Cairo ... how could        
> we suggest a workaround? I'd suggest that actually debugging the problem        
> would help move the process along...        
        
I think either you misinterpreted the tone of my last post, or I'm        
misinterpreting the tone of this one.  If I offended you, I'm sorry.   
   
My point was just that Eclipse is likely to need to write a workaround.  We   
don't understand the internals of pango or cairo well, and would appreciate   
help.  (At this point distributions have started shipping on broken versions  
of pango/cairo.)  
  
If you would like help debugging, then we're happy to lend some assistance.   
Behdad suggested a patch, which I've tried for him.  Unfortunately, it didn't  
work.  It might be helpful if you read     
https://bugs.eclipse.org/bugs/show_bug.cgi?id=123425, as it contains a little  
more detail about the effects we're seeing and things we've tried. 
 
Comment 8 Owen Taylor 2006-02-18 05:12:54 UTC
I didn't mean to sound offended :-), but I was just trying to indicate
that (as usual in free software), indicating that a bug is high priority
for you usually doesn't produce too many results, especially if it is
very hard to reproduce.

I hadn't followed the link to the bug, but it appears glancing at it,
that you guys have tracked it down to GTK+. If so, then  you need to
close this bug report, and open one against GTK+.

(Really, it would seem very easy to take that investigation one step
further and find the bug in that function. It might just be a 
incorrect rounding problem, say; but first step is to get the bug
report filed against the right place.)



Comment 9 Behdad Esfahbod 2006-02-18 06:16:56 UTC
Created attachment 4658 [details] [review]
gdk patch

Sorry I didn't feel like creating an account on Eclipse bugzilla.  Can you test
this Gtk+ patch and see if it's a fix?
Comment 10 Douglas Pollock 2006-02-18 07:12:41 UTC
I didn't include the change to gtklabel; it seemed like it was included in  
error.  The change to gdkpango.c doesn't seem to have any effect.  Does the 
small test program given in comment #0 work for you? 
 
Comment 11 Behdad Esfahbod 2006-02-18 07:16:39 UTC
That test case is too subtle for me to verify.  With my (rather huge) fonts, I
don't see anything bad.

If you have a C test program for the problem exposed in the Eclipse bug, I can
test it.
Comment 12 Douglas Pollock 2006-02-18 07:40:28 UTC
(In reply to comment #11)     
> That test case is too subtle for me to verify.  With my (rather huge) fonts,     
> I don't see anything bad.     
     
It is definitely subtle.  The Eclipse text selection issue is more jarring 
because it's one pixel of whitespace appearing throughout a text selection.  
But this only occurs in one of our custom widgets.  It also seems to occur 
regardless of font. 
     
I'm not sure what your set-up is like, but with a JRE   
(http://java.sun.com/j2se/1.5.0/download.jsp) and Eclipse   
(http://download.eclipse.org/eclipse/downloads/drops/R-3.1.2-200601181600/index.php),   
you could see the problem for yourself.   
  
Otherwise, I'm happy to keep trying patches, and generally helping out any way  
I can.  
 
Comment 13 Behdad Esfahbod 2006-02-18 08:42:09 UTC
No, I cannot test that really.
You said that the bug is in gdk_pango_layout_get_clip_region.  Can't you just
play with that function and see what's wrong?  My gdkpango patch does something
like that.  You can at least report to us that "the text extents pango reports
are these and these, and after rounding they become this with extended format,
but that with double" so at least we know whether it's a pango bug, or gtk+...

And other people can help if you open a bug against Gtk+...  It's not obvious
that it's a Cairo bug at all.
Comment 14 Felipe Heidrich 2006-04-07 08:20:58 UTC
Created attachment 5210 [details]
test case

This test case simulates a full selection text editor where the selection start
in the middle of a word and spams all the way to the end.
It uses clipping to draw a word that is half selected (to preserve arabic
ligatures for example). 

It works fine with older version of pango (1.6.0), it fails on pango 1.10.2
when the FPU mode is double. It works on pango 1.10.2 when FPU mode is extended
(which is the default).

Please, let me know if you need help to reproduce the problem.
Comment 15 Felipe Heidrich 2006-04-07 08:23:39 UTC
Created attachment 5211 [details]
failing scenario
Comment 16 Felipe Heidrich 2006-04-07 08:24:09 UTC
Created attachment 5212 [details]
working scenario
Comment 17 Felipe Heidrich 2006-04-07 08:28:14 UTC
In the failing scenario you can see the first selection box is short by one
pixel in the height and width, this is because gdk_pango_layout_get_clip_region
returns a region that is smaller.

Note: to reproduce the problem you MUST have the right text, font, pango
version, and fpu mode. I'm pretty sure this is a rounding problem and if you
change anything you can get lucky and everything works.
Comment 18 Behdad Esfahbod 2006-04-07 18:52:22 UTC
Ok, try with Pango from CVS head.  Should be fixed now.
If you confirm the fix really soon, I may push 1.12.2 out before Monday and it
will get into GNOME 2.14.1.

The bug was happening when a hinted metric of 27*1024 was showing up as 27647
instead of 27648, and then rounded down in gdk...  Gdk can use some help later,
but in the mean time, I rounded metrics when converting from cairo doubles to
Pango units by using:

#define PANGO_UNITS(Double) ((int)((Double) * PANGO_SCALE + 0.49999))

hoping that it works good enough even when the FPU is set to round instead of
floor...
Comment 19 Joshua Nichols 2006-04-13 05:48:04 UTC
(In reply to comment #18)
> Ok, try with Pango from CVS head.  Should be fixed now.
> If you confirm the fix really soon, I may push 1.12.2 out before Monday and it
> will get into GNOME 2.14.1.
> 
> The bug was happening when a hinted metric of 27*1024 was showing up as 27647
> instead of 27648, and then rounded down in gdk...  Gdk can use some help later,
> but in the mean time, I rounded metrics when converting from cairo doubles to
> Pango units by using:
> 
> #define PANGO_UNITS(Double) ((int)((Double) * PANGO_SCALE + 0.49999))
> 
> hoping that it works good enough even when the FPU is set to round instead of
> floor...

I'm a downstream maintainer of Eclipse for Gentoo. Finally got annoyed by the
highlighting problem to start looking into it, and came across this bug.

I tested a pango cvs snapshot from yesterday, and the Eclipse highlighting
problem goes away. Awesome.

Obviously, we missed the GNOME 2.14.1 release, but do you think we can see a
1.10.2 release before the next GNOME release?
Comment 20 Behdad Esfahbod 2006-04-13 06:07:40 UTC
Yes, this will be in the next version of GNOME.
Comment 21 Felipe Heidrich 2006-04-13 06:56:24 UTC
Behdad Esfahbod: 
Thanks for fixing this. But I need to support older version of gnome. So my 
question is:
Is there any workaround I can use in my code (besides play the FPU mode) to 
fix this ?
Comment 22 Behdad Esfahbod 2006-04-13 07:32:53 UTC
None that I know of.