Last Comment Bug 828073 - grayscale instead of sub-pixel AA in the urlbar
: grayscale instead of sub-pixel AA in the urlbar
Status: RESOLVED WORKSFORME
: regression
Product: Core
Classification: Components
Component: Graphics: Text (show other bugs)
: 15 Branch
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Lee Salzman [:lsalzman]
Mentors:
Depends on:
Blocks: 752918
  Show dependency treegraph
 
Reported: 2013-01-08 15:53 PST by al_9x
Modified: 2016-09-29 08:25 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fx 14 vs. Fx 15 (23.94 KB, image/png)
2013-01-08 15:53 PST, al_9x
no flags Details
urlbar selected text Fx 3.6 vs. Fx 18.0 (7.05 KB, image/png)
2013-01-09 02:34 PST, al_9x
no flags Details

Description User image al_9x 2013-01-08 15:53:19 PST
Created attachment 699484 [details]
Fx 14 vs. Fx 15

xp, new profiles, present in latest nightly, with or without acceleration
Comment 1 User image al_9x 2013-01-09 02:34:15 PST
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.
Comment 2 User image Alice0775 White 2013-01-09 05:15:22 PST
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
Comment 3 User image al_9x 2013-02-21 18:28:22 PST
@Jet Villegas - what's going on with this, can you fix it?
Comment 4 User image al_9x 2013-04-06 18:46:35 PDT
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
Comment 5 User image Jet Villegas (inactive) 2013-11-04 14:29:31 PST
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?
Comment 6 User image Jonathan Watt [:jwatt] 2013-11-04 15:27:34 PST
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?
Comment 7 User image Jonathan Watt [:jwatt] 2013-11-04 15:28:19 PST
That would have been "for a *clip path* on WinXP".
Comment 8 User image Bas Schouten (:bas.schouten) 2013-11-05 09:08:48 PST
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.
Comment 9 User image Matt Woodrow (:mattwoodrow) 2013-11-11 18:45:19 PST
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.
Comment 10 User image Matt Woodrow (:mattwoodrow) 2013-11-11 20:24:16 PST
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.
Comment 11 User image Dão Gottwald [::dao] 2014-04-30 15:08:01 PDT
*** Bug 1004167 has been marked as a duplicate of this bug. ***
Comment 12 User image Aibara Iduas 2014-04-30 21:03:20 PDT
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.
Comment 13 User image Dão Gottwald [::dao] 2014-05-01 00:21:53 PDT
(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.
Comment 14 User image Aibara Iduas 2014-07-22 13:25:18 PDT
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?
Comment 15 User image Elbart 2014-11-09 00:14:16 PST
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.
Comment 16 User image Karl Tomlinson (:karlt) 2015-06-02 20:32:32 PDT
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.
Comment 17 User image Karl Tomlinson (:karlt) 2015-06-02 20:44:18 PDT
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.
Comment 18 User image Karl Tomlinson (:karlt) 2015-06-04 15:47:47 PDT
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.
Comment 19 User image Anthony Hughes (:ashughes) [QA] 2016-09-27 13:45:07 PDT
Does this bug still reproduce in the latest Nightly?
Comment 20 User image Aibara Iduas 2016-09-28 18:48:08 PDT
Just tried it in Nightly (52.0a1; 2016-09-28; 64-bit) on Ubuntu 16.04. It is now rendering correctly!
Comment 21 User image Anthony Hughes (:ashughes) [QA] 2016-09-29 08:25:37 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.