xp, new profiles, present in latest nightly, with or without acceleration

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 Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/498d2784a240 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120514113854 Bad: http://hg.mozilla.org/mozilla-central/rev/3ab55d40ecd4 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120514140411 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=498d2784a240&tochange=3ab55d40ecd4 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/cf84757bce4b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120513215048 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/32209138048c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120514032248 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cf84757bce4b&tochange=32209138048c In local build: Last Good: 3eab6ea25342 First Bad: ec19a7304528 Triggered by: 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: https://mxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGIntegrationUtils.cpp?rev=6b6ea9376519&mark=499-503,510-511#493 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.

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 integer aligned. 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() when IsRectClippedByRoundedCorner(itemContent). 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.