Created attachment 699484 [details]
Fx 14 vs. Fx 15
xp, new profiles, present in latest nightly, with or without acceleration
Created attachment 699649 [details]
urlbar selected text Fx 3.6 vs. Fx 18.0
Selected text in the urlbar is a real mess. When it was rendered with cleartype there was still a problem (Bug 677144), now it's even worse. The last time it was properly rendered was 3.6.
this bug is xp specific (reproducible in a vm), I am not checking win7, win8, vista.
I can reproduce the problem in windows7 if HWA disbled
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120514113854
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120514140411
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120513215048
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120514032248
In local build:
Last Good: 3eab6ea25342
First Bad: ec19a7304528
ec19a7304528 Jet Villegas Bug 752918 - Convert expensive SVG masks to clip-paths. r=dao
@Jet Villegas - what's going on with this, can you fix it?
perhaps Mozilla research can put together a team to rediscover how to render text with proper native sub-pixel aa (cleartype)
clearly a lost art at this point: https://bug828073.bugzilla.mozilla.org/attachment.cgi?id=699649
jwatt: I don't get why moving from mask to clip-path SVG would change anti-aliasing behaviour for text. That is, I expect the text raster occurs independently of the clip. Can you have a look?
Changing from mask to clipPath means that we will now take the code path that is the second marked section here rather than the first:
So there's no longer an explicit PushGroup/PopGroup going on in the SVG code. That said, the clipPaths in bug 752918 are complex enough that I believe that Cairo will be doing one internally. Maybe where we pass PushGroup(GFX_CONTENT_COLOR_ALPHA) Cairo is internally using something different than GFX_CONTENT_COLOR_ALPHA when it creates an offscreen surface for a complex mask on WinXP?
Bas, can you shed any further light on this?
That would have been "for a *clip path* on WinXP".
If cairo -is- internally doing something like this, if it's creating a temporary surface with an alpha channel, it might very well not set the flag that says all text will be over opaque pixels. In that case it would not use subpixel anti-aliasing since text could be on top of partially transparent pixels.
I had a bit of a look at this while debugging 926023.
It's fairly easy to reproduce with layers acceleration and direct disabled.
Unfortunately, as far as I can tell, we should be drawing with ClearType enabled.
We get to here: http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-win32-font.c#1441 with use_subpixel_antialiasing = TRUE when drawing the url bar text.
I have no idea why GDI decides to ignore this and draw greyscale AA instead.
I also confirmed that painting the tab titles (which do get cleartype) go through the same path, and I also tried deleted the cached_hfont object in case our cached object didn't match what we thought it did.
*** Bug 1004167 has been marked as a duplicate of this bug. ***
Is 1004167 really a duplicate? While the problem seems to be the same, this bug describes an issue with the Windows version that's been around for quite some time. 1004167 involves Linux (which does not use ClaerType) and only affects version 29 and up.
(In reply to Aibara Iduas from comment #12)
> Is 1004167 really a duplicate? While the problem seems to be the same, this
> bug describes an issue with the Windows version that's been around for quite
> some time. 1004167 involves Linux (which does not use ClaerType)
This isn't a GDI/ClearType bug, though. There's something wrong in our layout or graphics code, much of which is cross-platform.
> and only affects version 29 and up.
On Linux, we only started attaching the back button to the location bar using an SVG clip-path in version 29. This makes us run into the same problem we ran into on Windows.
This is still an issue in Firefox 31. It's unfortunate that version 29, which made the UI look more modern, made the address bar so ugly on Linux. And to say nothing about those using XP, affected for over a year and a half.
It seems like fixing this will be difficult, but are there any known workarounds in the meantime?
It's not only the addressbar.
Also the tab-title and the searchbar only use grayscale AA with hwa off.
But on the other side the text in arrowpanelsuses cleartype.
Cairo typically doesn't do subpixel aa when there is a non-pixel-aligned clip.
When _cairo_image_surface_glyphs uses its _clip_and_composite, the
non-pixel-aligned clip triggers the need_clip_surface path with chooses
_clip_and_composite_with_mask, which creates a PIXMAN_a8 surface in
_create_composite_mask_pattern. The (component_alpha) glyphs are rendered to
that before combining with the clip.
_create_composite_mask_pattern in cairo-surface-fallback.c similarly creates a
CAIRO_CONTENT_ALPHA surface for rendering glyphs and combining the clip.
A particular surface type may have its own glyph compositing implementation but
_cairo_xlib_surface_show_glyphs and _cairo_win32_surface_show_glyphs_internal
bail if _cairo_clip_get_region fails. i.e. when the clip region is not
I guess a component alpha mask could be used with this approach, but even in
git cairo, create_composite_mask() in cairo-traps-compositor.c, used for image
surfaces looks similar with a single-alpha mask.
For a non-pixel-aligned clip, it is probably better to do something like
push-group to deal with the complex clip once rather than use it for drawing
every child. That would also give better results, as it wouldn't accumulate
the bleeds across the clip.
The simple push-group with color-single-alpha surface works for subpixel aa
only if children are drawing an opaque background before applying component
alpha masks for glyphs.
Usually subpixel aa is explicitly disabled on color-single-alpha surfaces that
are not know to be opaque, because the component alpha mask blend functions
used on many/most platforms don't necessarily extend appropriately when the
destination has non-unit alpha.
If the background is known to be opaque before the clip is applied, then
subpixel aa can be maintained on translucent children by copying the opaque
background to the pushed surface.
ContainerState::ProcessDisplayItems() uses SetupMaskLayer()
That sounds like the kind of thing required here, and perhaps the code can be shared somehow, but I don't know whether or not that provides subpixel aa.
Does this bug still reproduce in the latest Nightly?
Just tried it in Nightly (52.0a1; 2016-09-28; 64-bit) on Ubuntu 16.04. It is now rendering correctly!
(In reply to Aibara Iduas from comment #20)
> It is now rendering correctly!
Thanks for checking, Aibara. I am closing this bug since it no longer reproduces for you. Please reopen this bug report if the issue returns.