VRGB sub-pixel hinting causes black-on-black text rendering

[TJ]

Binary package hint: libcairo2

There is a long-standing problem (Gutsy, Hardy, Intrepid - possibly Jaunty too) with sub-pixel rendering which affects metacity or compiz composition (see the images attached to this bug) when VRGB is chosen as the sub-pixel format. Comment #15 by MoMaT demonstrates a non-compiz scenario. My comments #2 and #10 demonstrate the issue with Compiz enabled.

The underlying issue essentially seems to be: where should sub-pixel rendering should be done - in libcairo or in the font renderer (FreeType in this case) ?

There have been two versions of the Ubuntu patch in libcairo/libcairo2. Reports seem to suggest that both versions may be responsible for the VRGB problem (however, that supposition needs checking - see Bob McElrath's comment #19).

We need to be aware that libcairo (libcairo 1.5.4 in Universe) and libcairo2 (cairo 1.6.0 in Main) are similarly patched and will need similar fixes.

[Stanislav Brabec (sbrabec-suse)]

Created an attachment (id=9148)
cairo-1.2.4-lcd-filter-1.patch

[Stanislav Brabec (sbrabec-suse)]

It seems, that following URL may contain updated version of attached patch.
http://lists.gnu.org/archive/html/freetype/2006-10/msg00004.html

[Stanislav Brabec (sbrabec-suse)]

No, checking mail dates, cairo-1.2.4-lcd-filter-1.patch seems to be the latest I can find: http://<email address hidden>/msg01028.html

[Bugzilla-namtrac (bugzilla-namtrac)]

The patch gives impressive results when LCD filtering is enabled in Freetype, but it won't apply to 1.4.10 cleanly.

[Stanislav Brabec (sbrabec-suse)]

Created an attachment (id=10583)
cairo-1.4.10-lcd-filter-1.patch

My attempt to update patch for cairo 1.4.10.

[Bugzilla-namtrac (bugzilla-namtrac)]

Removing _cairo_error (CAIRO_STATUS_NO_MEMORY); from the code doesn't sound right :-/

[TJ (tj)]

Binary package hint: compiz

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.

When Compiz is disabled the resize legend appears correct.

[Basilio Kublik (sourcercito)]

Hi Tj
could you please attach a screenshot demonstrating this?

[Basilio Kublik (sourcercito)]

Hi there
sorry about the delay in the response, does this still happens, it has been a couple of upgrades since then and this issue could be solved by one of them.

[TJ (tj)]

I was just thinking earlier about how to further debug this. The problem is still present with the final release updates.

[Adrian Penisoara (adrian.penisoara)]

I am in the very same situation (gradual updates until final Gutsy release). I can think of two possible tests right now:
 1. "flush" all compiz settings in order to revert to default setup (or even certain plugin(s) settings)
 2. Switch to "i810" driver instead of "intel" driver
 3. upgrade or reinstall with a fresh Gutsy release CD

I would rather take option (1) from the two above.

Particular things to my machine: Dell laptop with Intel 945GM card using "intel" driver, 1280x1024 on CRT output, 1440x960 on LCD (with 915resolution). Let me know what other infos may be relevant in this context.

[Basilio Kublik (sourcercito)]

Hi Adrian
Could you please create a new user, and with this clean environment try to reproduce this issue?, I've never experience this and don't really know what could be causing it, I'm just shooting in the dark here.
I think it could be beneficial if you check this with normal/extra and custom desktop effects settings, and that way isolating the most probable culprit of this behavior.
TJ if you could also try this, i would greatly appreciate.

Thanks in advance.

[Adrian Penisoara (adrian.penisoara)]

I can confirm that creating a new user fixes the problem. I have "flushed" all GNOME configuration files in my home directory and the problem has disappeared.
I guess fixing up some or most of the ~/.gconf/apps/compiz/ hierarchy would resolve the problem.

I have not tried yet Preferences / Advanced Desktop Settings (need compizconfig) / Preferences / Reset to Defaults , although I remember to have used it once in the past.

[TJ (tj)]

Thanks to Basilio's suggestion and Adrian's test with a new user profile I was spurred into investigating this some more.

In System > Preferences > Advanced Desktop Effects Settings

In the Utility section, disabling "Resize Info" disables the effect.

With "Resize Info" enabled I played with the settings and discovered that what is happening is that the size info is beinf drawn as black text on a black background.

As soon as I altered the 'Text Color' setting to a colour that contrasts with black, the characters are visible, although the inverted display looks 'kludgy' and not like it used to be.

I've trawled through the changes just prior to the first time I noticed the issue for compiz-fusion-plugins-main and pango1.0-0, and been investigating cairo & pango since the crux of the issue is in

compiz-fusion-plugins-main/src/resizeinfo.c::updateTextLayer ()

where it does:

    cr = is->textLayer.cr;

    /* Clear the context. */
    cairo_save (cr);
    cairo_set_operator (cr, CAIRO_OPERATOR_CLEAR);
    cairo_paint (cr);
    cairo_restore (cr);
    cairo_set_operator (cr, CAIRO_OPERATOR_OVER);

    asprintf (&info, "%d x %d", xv, yv);

    font = pango_font_description_new ();
    layout = pango_cairo_create_layout (is->textLayer.cr);

    pango_font_description_set_family (font,"Sans");
    pango_font_description_set_absolute_size (font, 12 * PANGO_SCALE);
    pango_font_description_set_style (font, PANGO_STYLE_NORMAL);
    pango_font_description_set_weight (font, PANGO_WEIGHT_BOLD);

    pango_layout_set_font_description (layout, font);
    pango_layout_set_ellipsize (layout, PANGO_ELLIPSIZE_END);
    pango_layout_set_text (layout, info, -1);

    pango_layout_get_pixel_size (layout, &w, &h);

    cairo_move_to (cr,
     RESIZE_POPUP_WIDTH / 2.0f - w / 2.0f,
     RESIZE_POPUP_HEIGHT / 2.0f - h / 2.0f);

    pango_layout_set_width (layout, RESIZE_POPUP_WIDTH * PANGO_SCALE);
    pango_cairo_update_layout (cr, layout);

    cairo_set_source_rgba (cr,
      *(color) / (float)0xffff,
      *(color + 1) / (float)0xffff,
      *(color + 2) / (float)0xffff,
      *(color + 3) / (float)0xffff);

    pango_cairo_show_layout (cr, layout);

    pango_font_description_free (font);
    g_object_unref (layout);

It could be that font description or something related to the drawing mode used is causing the background of the glyphs to be drawn in pango_cairo_show_layout(). It is possible this may end up being caused by a change in Pango or Cairo that somehow upsets Compiz.

[TJ (tj)]

Adrian, are you using Gutsy x86 or x86_64 (AMD64) ?

I'm wondering if this might be an issue to do with 32-bit vs 64-bit values. If you're using 32-bit though, we can scrub that line of investigation.

[TJ (tj)]

Tracked down the apparent cause to libcairo's debian/patches/02-cairo-1.4.8-lcd-filter-2.dpatch.

The bug reveals itself if sub-pixel rendering is enabled and rgba_order 'VRGB' is selected.

 $ gconftool-2 -a /desktop/gnome/font_rendering
 rgba_order = vrgb
 antialiasing = rgba
 dpi = 96
 hinting = full

Changing it to any of the other options (vbgr, rgb, bgr) using

$ gconftool-2 -s /desktop/gnome/font_rendering/rgba_order -t string "vbgr"

and restarting Compiz (or disabling/re-enabling it) will clear the issue.

Working on a fix.

[TJ (tj)]

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

[TJ (tj)]

Slight correction to the manually re-edited IRC conversation above - I managed to mangle the speakers in part of it. Here's the correction:

cworth: But I don't really know what it's doing. And if you've found a bug in it now...
TJ: 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
TJ: (that's in the bit-flipping logic for VRGB)

[Basilio Kublik (sourcercito)]

Hi there
Thanks TJ for working on this, seems to be as you pointed a libcairo issue rather than compiz, so i'm leaving just the libcairo task open, if you don't think this is correct, please feel free to re-open it for the compiz package.

Thanks again for help to make Ubuntu better, keep up with the good work, and good luck with the issue ;-).

[Bugzilla-namtrac (bugzilla-namtrac)]

Behdad,

Is there any chance you are gonna apply this patch? This patch improves rendering a lot but its once again out of sync with cairo 1.5.2.

Please comment.

[Freedesktop (freedesktop)]

Looks good to me generally. Can go in 1.6 after testing.

[Bugzilla-namtrac (bugzilla-namtrac)]

Very good news, David Turner will like this news :-)

[Freedesktop (freedesktop)]

Well, he has a much larger chunk of code rewriting cairo-ft that is awaiting review...

[Bugzilla-namtrac (bugzilla-namtrac)]

(In reply to comment #10)
> Well, he has a much larger chunk of code rewriting cairo-ft that is awaiting
> review...

Must be private as I haven't seen it but his patches are always quality anyway, maybe its a good time to review it? :)

With this patch GTK+ apps looks really sharp.

[Freedesktop (freedesktop)]

It's been sent to cairo list multiple times (improved versions). Yes, his patches are very good, but it completely rewrites cairo-ft.c, so can use a review still.

I really like to get that in 1.6. Will see.

[Stanislav Brabec (sbrabec-suse)]

Please review carefully, porting of this patch was not trivial and I could make any mistake.

[Sylvain Pasche (sylvain-pasche)]

The Ubuntu developers slightly enhanced the patch:
"debian/patches/02-cairo-1.4.8-lcd-filter-2.dpatch:
    - Restore patch that uses the new FreeType LCD colour filtering features,
      with additional modification that the specific LCD Filter can be
      changed."
(you can get the source from http://packages.ubuntu.com/gutsy/libs/libcairo2)

I tried porting that patch on the trunk (as expected, it doesn't apply cleanly). However, glyph positioning is broken. I'll try to debug this when I have time.

[Sylvain Pasche (sylvain-pasche)]

Created an attachment (id=12910)
text-rotate testcase after ported patch

Compare with reference: http://gitweb.freedesktop.org/?p=cairo;a=blob;h=b2273989263552c3bb8ddb7d27a2eb319857da4a;hb=9c732594039b164a1e08125c35ec9d04278f0cbf;f=test/text-rotate-ref.png

[Sylvain Pasche (sylvain-pasche)]

I forgot to add:

I looked at the freetype rewrite patches from David Turner (http://david.freetype.org/cairo/fix-freetype-usage-4.patchset), but they do not seem to have the lcd-filtering enhancement proposed here (I saw no FT_Library_SetLcdFilter call). So these two changes should be independent (of course, the patch here might need large adaptations to by applied on top of the freetype rewrite).

[MoMaT (momat)]

Confirming. With the Desktop Effects disabled I has the same bug when displaying SVG in Firefox. Switching away from subpixel rendering (VRGB) to the best shape and back solved the issue.

[Brandon Wright (bearoso-deactivatedaccount)]

I would like to see this go into 1.6 as well. It seems many packagers are already using it, so it wouldn't hurt, and it makes sub-pixel rendering much better looking.

[Brandon Wright (bearoso-deactivatedaccount)]

Created an attachment (id=12955)
Incorrect glyph positioning on 1.5 branch

I've applied the patch to cairo 1.5.2 after some fuzzing, but it seems I've run into the same glyph layout issue Sylvain encountered.

I've attached a screenshot from my GNOME appearance pane. It was the only location I could find where the the labels are large enough to avoid completely clipping the text. It appears from this that the vertical positioning is significantly off, but the horizontal positioning is only wrong by a few pixels on some glyphs.

[Sylvain Pasche (sylvain-pasche)]

Created an attachment (id=12971)
patch for 1.5

The patch needed to be updated according to 31f5aafa36015ee6ea8ff769c2e1d5841f62642f.

This is now running quite better.

Tests will need to be updated / completed.

[Sylvain Pasche (sylvain-pasche)]

Behdad,

Do you prefer to wait for the freetype rewrite before dealing with this bug? As I said in comment 16, the freetype rewrite will not automatically solve this issue.

Otherwise, I can help with the test update or cleanup if you think you can make it for 1.6.

[Brandon Wright (bearoso-deactivatedaccount)]

Sylvain, your ported patch requires definitions that come from Ubuntu's supplementary patch to fontconfig. You either need to get that patch into fontconfig upstream or remove the added options from the cairo patch.

As an added note, even after patching fontconfig and building from your patch, the fontconfig additions don't seem to have any effect. In fact, the original Ubuntu-modified changeset to Cairo has a significant error where they use FC_LCD_FILTER_* definitions where they should be using FT_LCD_FILTER_* to pass to FT_Library_SetLcdFilter. I checked the headers, and the definitions don't correspond. This leads me to believe that their changes never did what they were supposed to in the first place.

[Brandon Wright (bearoso-deactivatedaccount)]

Created an attachment (id=12997)
Silvain's patch against 1.5, modified to use correct definitions.

Some definitions needed editing to make the filter configuration from Ubuntu work. This patch contains those modifications.

[Brandon Wright (bearoso-deactivatedaccount)]

I've created bug 13566 with the modification patch to fontconfig that allows the cairo patch to apply.

[Bugzilla-namtrac (bugzilla-namtrac)]

(In reply to comment #23)
> I've created bug 13566 with the modification patch to fontconfig that allows
> the cairo patch to apply.

Tested with cairo 1.5.4 and fontconfig 2.5.0 with patches for each, works fine.

[Brandon Wright (bearoso-deactivatedaccount)]

(In reply to comment #69)
> Nicolaus, what source tree is your patch based on? I can't get it to apply to
> either 1.8.0 or master.
Ok, I see it applies well enough against master with commit 5d887ad5dca5af0f8216830d1b04d08a5aba9bee reverted.

[Nicolaus Lance Hepler (nlhepler)]

Yea, it applies to a revert of the revert of the lcd_filtering functionality. There's still some stupid crap in that code, I realize, so I'm going to go over it again. But at least it works.

[Carl Worth (cworth)]

(In reply to comment #68)
> Carl, you really should try maintaining a distro's text stack for a couple
> years before you get it: There is no sensible defaults. People file bugs
> about their text rendering where it looks perfectly fine to me. Certainly much
> better than what they call the unbuggy version. Choosing filters based on
> hintstyle, or exposing some but not other filters is simply not cairo's
> business. Smple as that.

I don't buy it, Behdad.

Certainly, you have experience that I don't here. I don't content that. And users often do want text-rendering results that seem hard to believe---I've seen that.

But as for the details of which kind of LCD filtering---your distribution has never made that available as an option, right? So what evidence do you have that people won't be satisfied here? Just that "they're never satisfied"?

I'd really like to do something very much like "strong hinting"->"current filtering" and "slight/medium hinting"->"freetype's FIR5 filtering" and see if that satisfies people. And best would be to do that experiment by way of the new text-preferences dialog where people choose the version that they like the best. I really can't imagine many people saying "none of the above". (I think most hard-to-understand complaints come from people not being able to achieve a result that they are accustomed to---and that's precisely part of the reason that led to the revert of the freetype-filter using code during 1.7.x.)

-Carl

[Brandon Wright (bearoso-deactivatedaccount)]

Sorry for bringing this bug up again, but I noticed cairo 1.8.4 is now out, and I was wondering what else needed to be done to put filtering back into the next point release (if it's still possible). What are everyone's opinions of Nicolaus's patch, and is something else required that his patch doesn't handle?

[Edouard Laroche-Joubert (elarochejoubert)]

I'm using Hardy and I've got the problem as well. But I think it's more than "low" priority because it concerns more than just the resizing info. A lot of things are rendered like think.
For example: selecting text in firefox then drag it in somewhere has the same effect.
Another example is the legend in compiz windows thumbnail preview.
etc..

[Nicolaus Lance Hepler (nlhepler)]

Created an attachment (id=21150)
Fallback to cairo's original LCD filtering if freetype lacks the capacity

Here's an updated patch for mainline, applies directly to HEAD.
I've compile-tested it, and a derivative of the patch on a VirtualBoxed Ubuntu Intrepid System. It works, but it's not HEAD.
If anyone finds any bugs, please let me know.
Now that classes are in remission and I'm no longer over-taxing myself, I'd really like to get this issue resolved.
There's been some discussion from Carl on what he'd like to see, but nothing really decided upon. If we could have a discussion and lay down what needs to be done to get these Freetype filtering patches upstream, that'd be a step in the right direction.

Thanks everyone!

Nicolaus

[Nicolaus Lance Hepler (nlhepler)]

This is a gentle >>nudge<<.
Behdad or Carl, can either one or both of you suggest a plan of action?
I would like to get the ball moving on this one.
We currently have downstream distros differing on this issue greatly, the situation could easily be improved.

Nicolaus

[Brandon Wright (bearoso-deactivatedaccount)]

Nicolaus, I tested your latest patch against HEAD, and it has a bug where grayscale or monocolor fonts are extra-wide. I've also tested HEAD with just reverting 5d887ad5dca5af0f8216830d1b04d08a5aba9bee and fixing the conflicts, and the bug isn't there. It looks like something in your patch is multiplying a number against the width/pitch when it shouldn't be, or not dividing it out when it should. Since both your original patch and HEAD with the revert work fine, I figure you'll know if you changed something along these lines that might be causing it.

[Nicolaus Lance Hepler (nlhepler)]

Thanks Brandon, I'll take a look.
There's probably some thinko somewhere.

[Bob+freedesktop (bob+freedesktop)]

Ubuntu has included this patch, for some reason, and it causes a problem with drawing black-on-black text sometimes when VRGB subpixel smoothing is selected. The ubuntu bug is:

https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/145604

It appears there might be a byte-shift problem in this patch.

[Bob McElrath (bob+ubuntu)]

This bug is still in Intrepid. Let's fix it?

I ripped out the debian/patches/04_lcd_filter.dpatch and recompiled. This fixes the bug both in resizing windows and other apps (like firefox) painting some text incorrectly. As described above, it only happens with VRGB subpixel smoothing.

Why is this patch in ubuntu in the first place?

The related cairo bug is https://bugs.freedesktop.org/show_bug.cgi?id=10301

P.S. why was this defaulted to VRGB pixel order? How does X decide what the correct pixel ordering is? Presumably, three of these options are incorrect for my monitor...

[Sylvain Pasche (sylvain-pasche)]

> Why is this patch in ubuntu in the first place?

Because without it fonts look really ugly. That's a personal taste, but I think it reflects the opinion of the majority of users.

IMHO, The real question is why it is still not included in upstream Cairo.

[TJ (tj)]

Since upstream can't make up their minds on this I've un-assigned myself - it doesn't look like this is going to be addressed any time soon. I had been hopeful of some kind of resolution that we could implement as an SRU. I've added a bug-track link to the upstream bug report.

When using VRGB sub-pixel hinting this issue will occur. The easiest workaround (one I've used with Gutsy, Hardy, and Intrepid) is:

gconftool-2 -s /desktop/gnome/font_rendering/rgba_order -t string "vbgr"

[Nicolaus Lance Hepler (nlhepler)]

Brandon,

Sorry for taking so long to get back. I poured over my changes, and didn't notice anything out-of-ordinary, save for a single function call that was unnecessary, and probably wasn't the root of the problem. Could you tell me your use case, where you see this problem in the patch?

Lance

(In reply to comment #76)
> Nicolaus, I tested your latest patch against HEAD, and it has a bug where
> grayscale or monocolor fonts are extra-wide. I've also tested HEAD with just
> reverting 5d887ad5dca5af0f8216830d1b04d08a5aba9bee and fixing the conflicts,
> and the bug isn't there. It looks like something in your patch is multiplying a
> number against the width/pitch when it shouldn't be, or not dividing it out
> when it should. Since both your original patch and HEAD with the revert work
> fine, I figure you'll know if you changed something along these lines that
> might be causing it.
>

[Nicolaus Lance Hepler (nlhepler)]

Bob,

Can you open up and look at the version of cairo used by ubuntu, and apply the 04_lcd_filter.dpatch?

In _fill_xrender_bitmap, look at the section near the end, where it converts vertical RGB into ARGB32. There is a weird #if 1 #else #endif block in this particular section, and I think this is where the problem is. I think the code in the #else block is the correct code, and changing the #if 1 to #if 0 in the 04_lcd_filter.dpatch might fix it. (you'll need either a copy of the libcairo2-2ubuntu1 source to compile from or you'll need to revert the patch. There's some other stipulations about compiling that you might already know, like you can't have the original gzipped or bzipped tars of the source in the parent directory, or the devscipts will use them to build from.)

If anyone else is enlightened as to the math this is trying to perform, and can tell me for sure that I'm wrong about this particular section screwing up, I will gladly listen (and learn).

Sylvain, can you look into this? I don't have a platform handy for looking up their most obvious use case in Compiz, and I can't get Firefox to do what they say on a couple handy examples.

It would be nice to have this fixed as well as getting a working version of the fallback patch finally upstream. I wish my time wasn't so spotty, but it would also be encouraging to hear from either Behdad or Carl. I know Cairo is a cross-platform tool, and these guys have to worry about other things cropping up elsewhere, but these patches really help usability for some of the linux guys. I know Behdad isn't fired up about this issue, but you, Brandon, and I at least see a point to getting these patches upstream in some acceptable form.

Nicolaus (Lance)

(In reply to comment #78)
> Ubuntu has included this patch, for some reason, and it causes a problem with
> drawing black-on-black text sometimes when VRGB subpixel smoothing is selected.
> The ubuntu bug is:
>
> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/145604
>
> It appears there might be a byte-shift problem in this patch.
>

[Sylvain Pasche (sylvain-pasche)]

You seem to be right, the code in "#if 1", sets the alpha channel to full opacity (0xff), so the background behind the glyph won't be visible.
The else sets the alpha to the value of the green channel (same thing as horizontal RGB).

I don't have time right now for looking at this, but could someone test with that change? That may be an easy fix.

[Sylvain Pasche (sylvain-pasche)]

Good news: Nicolaus may have found the issue. If someone could try to recompile cairo with the change described in https://bugs.freedesktop.org/show_bug.cgi?id=10301#c80 and then report if the problem is solved, that would help.

[Carl Worth (cworth)]

(In reply to comment #80)
> It would be nice to have this fixed as well as getting a working version of the
> fallback patch finally upstream. I wish my time wasn't so spotty, but it would
> also be encouraging to hear from either Behdad or Carl. I know Cairo is a
> cross-platform tool, and these guys have to worry about other things cropping
> up elsewhere, but these patches really help usability for some of the linux
> guys. I know Behdad isn't fired up about this issue, but you, Brandon, and I at
> least see a point to getting these patches upstream in some acceptable form.

I still feel the some way about the API issues as I did when I wrote comment #67 above. Has anyone written a patch to address my concerns there?

Also, Behdad's latest review identified some bugs in the patch he saw as well. Have those been addressed?

-Carl

[TJ (tj)]

I'm building cario packages in my PPA for testing. I've simply inverted the "#if 1" to "#if 0" in the patch and bumped the package version.

https://launchpad.net/~intuitivenipple/+archive/ppa?field.name_filter=cairo&field.status_filter=published&field.series_filter=any

The Hardy package is based on hardy-updates (1.6.0-0ubuntu2):

cairo (1.6.0-0ubuntu3~tj~ppa1h) hardy; urgency=low

  * Fix debian/patches/02-lcd_filter_freedesktop_bug10301.dpatch:
    Use alpha-channel for FT_PIXEL_MODE_LCD_V in _fill_xrender_bitmap (LP: #145604)

 -- TJ <email address hidden> Mon, 26 Jan 2009 23:00:00 +0100

The Intrepid package is based on intrepid-updates (1.8.0-0ubuntu1.1):

cairo (1.8.0-0ubuntu1.2~tj~ppa1i) intrepid; urgency=low

  * Fix debian/patches/04-lcd_filter.dpatch:
    Use alpha-channel for FT_PIXEL_MODE_LCD_V in _fill_xrender_bitmap (LP: #145604)

 -- TJ <email address hidden> Mon, 26 Jan 2009 23:00:00 +0100

The Jaunty package is based on jaunty (1.8.6-1ubuntu1):

cairo (1.8.6-1ubuntu2~tj~ppa1j) jaunty; urgency=low

  * Fix debian/patches/04-lcd_filter.dpatch:
    Use alpha-channel for FT_PIXEL_MODE_LCD_V in _fill_xrender_bitmap (LP: #145604)

 -- TJ <email address hidden> Mon, 26 Jan 2009 23:00:00 +0100

[Nicolaus Lance Hepler (nlhepler)]

(In reply to comment #82)

I will initiate an API discussion later today on the cairo mailing list, then. I was hoping Behdad's short quip (comment #68) was enough to convince you, but a discussion is probably for the best.

Latest review? I went hunting around the mailing lists looking for said review, but could not find it. At least nothing after it was removed prior to 1.8.0. Are you talking about something before? I should hop onto the irc channel. I would relish the opportunity to dig in and learn more about these APIs.

Nicolaus

> (In reply to comment #80)
> > It would be nice to have this fixed as well as getting a working version of the
> > fallback patch finally upstream. I wish my time wasn't so spotty, but it would
> > also be encouraging to hear from either Behdad or Carl. I know Cairo is a
> > cross-platform tool, and these guys have to worry about other things cropping
> > up elsewhere, but these patches really help usability for some of the linux
> > guys. I know Behdad isn't fired up about this issue, but you, Brandon, and I at
> > least see a point to getting these patches upstream in some acceptable form.
>
>
> I still feel the some way about the API issues as I did when I wrote comment
> #67 above. Has anyone written a patch to address my concerns there?
>
> Also, Behdad's latest review identified some bugs in the patch he saw as well.
> Have those been addressed?
>
> -Carl
>

[Carl Worth (cworth)]

(In reply to comment #83)
> (In reply to comment #82)
> I will initiate an API discussion later today on the cairo mailing list, then.
> I was hoping Behdad's short quip (comment #68) was enough to convince you, but
> a discussion is probably for the best.

You can see my reply to that above. But I'd already asked for this discussion to happen on the list, not in this bug report. So, I think it's great you'll be taking it up there.

> Latest review? I went hunting around the mailing lists looking for said review,
> but could not find it.

I was talking about comment #76. But I misread that---it was from Brandon, not Behdad. But I still would like to know if those issued have been fixed.

> Are you talking about something before? I should hop onto the irc channel. I
> would relish the opportunity to dig in and learn more about these APIs.

I'll look forward to chatting with you there.

-Carl

[Brandon Wright (bearoso-deactivatedaccount)]

Created an attachment (id=22299)
Screenshot showing error from latest patch

Nicolaus, here's a screenshot showing the problem I'm getting. When grayscale or no smoothing is used, all the font metrics seem to be scaled horizontally. Also, it seems that even when disabling antialiasing, it still ends up using grayscale smoothing.

[Brandon Wright (bearoso-deactivatedaccount)]

Created an attachment (id=22302)
Revised version of "Fallback to cairo's original LCD filtering if freetype lacks the capacity"

Ok, I've discovered the problem for my issues. Referring to a patched version of master, On line 1431 of src/cairo-ft-font.c it tests against the variable ft_can_filter. However, this variable is only initialized on line 1367 if it's performing subpixel antialiasing, otherwise it's always false. It ends up using the internal glyph rasterizer, while it has everything set up for the external one. Moving the line 1431 testing block to the top level fixes the problem, with the addition of an extra line to put FT_SetLcdFilter back to normal.

Attached is a version of the patch with said changes made. While I was modifying it, I noticed that there are some tab/space formatting issues with the patch that might need to be cleared up.

[Nicolaus Lance Hepler (nlhepler)]

Created an attachment (id=22336)
Revised Revised version of the Freetype Filtering with Fallback patch

Hi Brandon,

Thanks for catching that! I clearly had a thinko in there. But I don't think that bug was causing the behavior you saw. I'm also curious how your changes fixed it for you. I recreated the effect you saw, and your patch didn't fix it for me. Although it clearly fixes a bug that would have cropped up otherwise.

I did a more thorough review, and discovered a code block that had been lost. I've stuck it back in, and it fixes the problem for me. I've also tried to clean up as many of the spacing issues as I could see.

Nicolaus

[Brandon Wright (bearoso-deactivatedaccount)]

(In reply to comment #87)
> Created an attachment (id=22336) [details]
> Revised Revised version of the Freetype Filtering with Fallback patch
>
> Hi Brandon,
>
> Thanks for catching that! I clearly had a thinko in there. But I don't think
> that bug was causing the behavior you saw. I'm also curious how your changes
> fixed it for you. I recreated the effect you saw, and your patch didn't fix it
> for me. Although it clearly fixes a bug that would have cropped up otherwise.
>
> I did a more thorough review, and discovered a code block that had been lost.
> I've stuck it back in, and it fixes the problem for me. I've also tried to
> clean up as many of the spacing issues as I could see.
>
> Nicolaus

It was hitting the correct code path everywhere but in that function, and the change I made ensured the FT_SetLcdFilter path was used properly there as well. Your missing code block caused another separate mixed code path error, and you had the right config to trigger it.

I tested your latest patch, and it works correctly.

[Jan David Mol (jjdmol)]

Confirmed on Jaunty. I have non-transparent white text on black, which shows up everywhere Compiz seems to put text (emerald window titles, scale window titles, resize info, application switcher window titles, etc). Example screenshot attached for the heck of it.

[Luke Ashe-Browne (lukeab)]

Just to re-itterate success in experiencing this problem and solving it with the gconftool command suggested above.
Problem experienced across upgrades between Intrepid and Jaunty on 64bit dell Latitude D630.

Attempt 2 to write this comment.

I was experiencing issues which match this bug.
Text in browsers during fade in or out transitions were blocky.
Text in gnome-terminal when using a transparent background, the background blocks behind the text glyphs where less transparent than th rest of the empty space in the console window.
banshee player status popup would have blocky text during fade in or out.

Generally matching all the properties of this bug.
running the gconftool-2 -s /desktop/gnome/font_rendering/rgba_order -t string "vbgr" command cleared the issue up immediately, without restarting compiz or browsers or console windows.

Thank you very much for the solution, was annoying as all heck.

[Luke Ashe-Browne (lukeab)]

Correction to above,
Upoon opening a few more web pages and rechecking Banshee status popup, i did have to restart firefox (tested twitter.com where i knew i had seen the effect before) and Banshee to clear the text blockyness. Worked on console without restart oddly enough.

Still a successful fix. Thank you very very much.

I wanted to ask is there any issue with performance or display quality now, switching order of the rgba to "vbgr" ? Why was it rgbv previously?

[Chris Wilson (ickle)]

I've applied the internal interface to pass the LCD filter option from fontconfig/screen resources to freetype. The interface is not ready to be made public yet, and I am uncertain about the removal of all fallback filtering for Cairo.

commit 7a023a62f7517ad0d54f4d59c99909fadcc05e82
Author: Nicolaus L Helper <email address hidden>
Date: Thu Jun 17 08:56:30 2010 +0100

    ft,fc,xlib: LCD filtering patch.

    This adds internal API to retrieve the LCD filtering parameters from
    fontconfig, or as set on the Screen, and feed them to FreeType when
    rendering the glyph.

    References:
      Bug 10301 - LCD filtering patch
      https://bugs.freedesktop.org/show_bug.cgi?id=10301

    Tested-by: Brandon Wright <email address hidden>
    Forward-ported-by: Robert Hooker <email address hidden>

    ickle: The API is clearly not ready for public consumption, the enum are
    poorly named, however this stands by itself as enabling system wide
    properties.

[Chris Wilson (ickle)]

*** Bug 27721 has been marked as a duplicate of this bug. ***

[Nicolaus Lance Hepler (nlhepler)]

I think the patch you applied should really be credited to whomever did the original patch (David Turner and Sylvain Pasche?), as all the fallback code I jimmied with is gone (also, it was mostly just playing with others' code).

Also, in _fill_xrender_bitmap in the FT_PIXEL_MODE_LCD_V part of the switch, there's an #if 1 ... 0xFF000000 ; #else ... #endif which makes it fully opaque. I would remove everything in the #if 1 ... #else section, and keep what's in the #else ... #endif.

N

> I've applied the internal interface to pass the LCD filter option from
> fontconfig/screen resources to freetype. The interface is not ready to be made
> public yet, and I am uncertain about the removal of all fallback filtering for
> Cairo.
>
> commit 7a023a62f7517ad0d54f4d59c99909fadcc05e82
> Author: Nicolaus L Helper <email address hidden>
> Date: Thu Jun 17 08:56:30 2010 +0100
>
> ft,fc,xlib: LCD filtering patch.
>
> This adds internal API to retrieve the LCD filtering parameters from
> fontconfig, or as set on the Screen, and feed them to FreeType when
> rendering the glyph.
>
> References:
> Bug 10301 - LCD filtering patch
> https://bugs.freedesktop.org/show_bug.cgi?id=10301
>
> Tested-by: Brandon Wright <email address hidden>
> Forward-ported-by: Robert Hooker <email address hidden>
>
> ickle: The API is clearly not ready for public consumption, the enum are
> poorly named, however this stands by itself as enabling system wide
> properties.

[Nicolaus Lance Hepler (nlhepler)]

Created an attachment (id=36349)
fix alpha mapping in vertical RGB to ARGB32 conversion

Fixes the alpha mapping for vertical RGB in _fill_xrender_bitmap in cairo-ft-font.c

[Ranma42 (ranma42)]

commit a150371a5d10e03d6c0d781c6fac950a9ac6be18
Author: Nicolaus L Hepler <email address hidden>
Date: Tue Aug 10 09:34:39 2010 +0200

    ft-font: Make alpha mapping consistent

    Vertical RGB mapping previously forced opaque pixels.
    To be consistent with horizontal RGB/BGR and vertical BGR it
    should use an alpha equal to the mid channel (green).

[Paul Ni (nikulinpi-gmail)]

Created attachment 40431
Allow changing of hintstyles by FC

http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/

[greg (grigorig)]

Like some others, I also object to keeping the "legacy" filter as the default. Freetype doesn't call it legacy without reason: it is optimized for one special rendering preference, full native hinting (IMO it's doing badly even in that case), and is crap in all others. Moreover, if the fonts do not have high-quality hinting instructions, it does a bad job as well. I think this isn't even subjective, the color fringing of the "legacy" filter is bad regardless of display and/or personal preferences.

If you still think it matters to not "surprise" users (I certainly would call improved text rendering a good surprise, though), the FIR3 filter might be a good choice for the default, but I'd surely go for the default (FIR5) by default. This is how it should be anyway.

[Zhou Yi Chao (broken-zhou)]

I am trying to enable subpixel rendering on poppler and I found my rendering result is suboptimal. After gdbing into cairo, I am surprise that cairo is still using the legacy filter as the "default". To the the situation even worse, cairo removed the interfaces to set the lcdfiler (cairo_font_options_set_lcd_filter) because "they are too specific to FreeType".

Well, maybe that is true. But now how can I use the real Freetype default filter (FIR5) in the newest cairo without pathcing it? I think maybe manually set a FcPattern is OK but I really do not want to learn/invoke/rely Fontconfig just for setting a filter that should be default.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/310.

[Carolinewebb78 (carolinewebb78)]

It was nice to get update on the patch for LCD filtering from SuSE builds shared by David Turner, one of the freetype2 upstream developers that means a lot for users to refer his concern about regarding the LCD filtering and the Cairo patch are all on a public.

Caroline,
http://www.personalstatementfolks.co.uk/

[Emadyassen1998 (emadyassen1998)]

good post.
http://www.winmilliongame.com
http://www.gtagame100.com
http://www.subway-game.com
http://www.zumagame100.com