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.
Created attachment 3949 [details] bad.png
Created attachment 3950 [details] good.png
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?
I'll try out the patch. Note that this is on x86 not x86-64.
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....
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...
(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.
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.)
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?
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?
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.
(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.
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.
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.
Created attachment 5211 [details] failing scenario
Created attachment 5212 [details] working scenario
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.
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...
(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?
Yes, this will be in the next version of GNOME.
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 ?
None that I know of.
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.