Scott (Keybuk) has confirmed the issue on x_86 32-bit as well. It looks as if the patch we have here is based on one originally submitted to Cairo in October 2005 by Frederic Crozat of Mandriva.
http://lists.cairographics.org/archives/cairo/2005-October/005550.html In that mail-list thread the suggestion is that the patch was to be incorporated into Cairo but it hasn't been. I've had a conversation with Carl Worth (cworth) of the Cairo development team. In part he said: cworth: It doesn't look like the cairo-subpixel-bgr.patch was ever applied. TJ: That'd explain why we have the patch :p cworth: Not really. Someone should have told us to apply it cworth: There's really not a good reason for distributions to carry cairo patches. TJ: Maybe there's reasons it was never added to the mainline of cairo? cworth: I think it was just missed. Carl: But I don't really know what it's doing. And if you've found a bug in it now... cworth: In looking it over I'm already concerned on how it casts unsigned char * to unsigned int * then assigns the unsigned int into an unsigned char array using a cast... on my 64-bit that doesn't write in a nice 32-bit RGBA, it writes 8 bytes, and at the end could also cause a buffer overflow cworth: (that's in the bit-flipping logic for VRGB) ... cworth: No, cairo takes subpixel LCD formats into account. cworth: I don't know what the patch is doing. cworth: Maybe cairo's doing it wrong in some cases or something... This suggests we need to revisit the reasons for the patch itself since Carl is of the opinion cairo should be supporting LCD formats already. As I learn more I'll add it to this bug report so everyone interested can see/contribute knowledge about it. Incidentally, running the libcairo test suite results in all the "text- antialias-subpixel" tests failing, presumably because the reference images need updating and including in the patch. There is an image attached to the mailing-list submission but it appears the format has been superseded : $ cd debian/build-main $ make check ... TESTING text-antialias-subpixel Tests text rendering with subpixel antialiasing text-antialias-subpixel-image-argb32 [0]: FAIL text-antialias-subpixel-image-argb32 [25]: FAIL text-antialias-subpixel-image-rgb24 [0]: FAIL text-antialias-subpixel-image-rgb24 [25]: FAIL text-antialias-subpixel-xlib-argb32 [0]: FAIL text-antialias-subpixel-xlib-argb32 [25]: FAIL text-antialias-subpixel-xlib-rgb24 [0]: FAIL text-antialias-subpixel-xlib-rgb24 [25]: FAIL text-antialias-subpixel-ps-argb32 [0]: UNTESTED text-antialias-subpixel-ps-argb32 [25]: UNTESTED text-antialias-subpixel-ps-rgb24 [0]: UNTESTED text-antialias-subpixel-ps-rgb24 [25]: UNTESTED Check text-antialias-subpixel.log out for more information. FAIL: text-antialias-subpixel ** Description changed: - Binary package hint: compiz-fusion-plugins-main + Binary package hint: libcairo Gutsy x86_64. Whilst Compiz is enabled if a gnome-terminal window is drag-resized the legend displaying the size during dragging is displayed as blocks rather than numbers. The same thing occurs to all windows if the Fusion plug-in resizeinfo has its 'always_show' property set. Changing resizeinfo's 'text_color' to something other than black reveals that the legend is being rendered but the background of each character block is also being filled (with black). So by default it draws black on black, resulting in the impression that only blocks are being displayed. When Compiz is disabled the resize legend appears correct (not drawn by the fusion plug-in). -- Compiz resizeinfo legend characters appear as filled blocks https://bugs.launchpad.net/bugs/145604 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
