Closed Bug 1020778 Opened 10 years ago Closed 10 years ago

Alpha scrolling in Contacts is not working fine

Categories

(Core :: Graphics, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla33
blocking-b2g 2.0+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: oteo, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(19 files, 8 obsolete files)

4.72 KB, patch
Details | Diff | Splinter Review
207.34 KB, image/png
Details
143.25 KB, image/png
Details
96.77 KB, image/png
Details
206.06 KB, image/png
Details
340.43 KB, image/png
Details
206.06 KB, image/png
Details
302.55 KB, image/png
Details
94.64 KB, image/png
Details
131.34 KB, image/png
Details
110.52 KB, image/png
Details
171.81 KB, image/png
Details
248.54 KB, image/png
Details
393.75 KB, image/png
Details
51.70 KB, image/png
Details
70.10 KB, image/png
Details
243.39 KB, image/png
Details
5.36 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
4.10 MB, video/mp4
Details
See these videos to check the regression in the Alpha scrolling in Contacts in master Master: https://www.youtube.com/watch?v=VXThk1t4dno v1.4: https://www.youtube.com/watch?v=UawvwcFR3mg Master build: hamachi B-185 Gecko-3e5340d Gaia-e508b51 v1.4 Build: hamachi B-80 Gecko-080d2fc Gaia-ba8d7ef
blocking-b2g: --- → 2.0?
This might be a regression from low res tiling. Can we see if the regression window in https://bugzilla.mozilla.org/show_bug.cgi?id=1018387#c7 also applies to this bug?
blocking-b2g: 2.0? → 2.0+
QA Contact: pcheng
Yes, I confirmed that the regression window is the same as what was posted at https://bugzilla.mozilla.org/show_bug.cgi?id=1018387#c7 Last working build does not repro the bug on Buri, and First broken build repro's the bug on Buri.
Blocks: 993473
Component: Graphics: Layers → Panning and Zooming
I don't know if this is fixable; text will just look nasty. We can try with some filters to reduce the "contrast" or some such, or just have to turn it off. Or, it could be an actual bug.
Assignee: nobody → bugmail.mozilla
(In reply to Milan Sreckovic [:milan] from comment #3) > I don't know if this is fixable; text will just look nasty. We can try with > some filters to reduce the "contrast" or some such, or just have to turn it > off. Or, it could be an actual bug. If we can't fix this, then we might need to pref off. This is happening across the entire OS (not just contacts, as I've seen this in the settings app) & it makes the scrolling experience look unpleasant.
Yes, we're working with UX on this.
Please clarify what you think is incorrect in the video in comment 0. The blurry text is expected and replaces what would otherwise have been just blank white. It does look a little too dark and that's something we can adjust, but I want to make sure there's no other problems here.
Flags: needinfo?(oteo)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7) > Please clarify what you think is incorrect in the video in comment 0. The > blurry text is expected and replaces what would otherwise have been just > blank white. It does look a little too dark and that's something we can > adjust, but I want to make sure there's no other problems here. I think that might be what's causing the confusion here. The bug bash showed high evidence that people thought the blurry text was a bug, not something that was expected.
This is a simple adjustment that reduces the darkness of the text in low-res. Botond, if you have some time, can you throw this into a build and run it by Gordon to see if he likes it? I'm not sure if the way I implemented it is "correct" because it might result in alpha blending with garbage underneath but I mostly want to check if an opacity change is sufficient or we should look for a more complex filter.
Attachment #8436540 - Flags: feedback?(gbrander)
Flags: needinfo?(botond)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > Botond, if you have some time, can you throw this into a build and > run it by Gordon to see if he likes it? Will do!
(In reply to Botond Ballo [:botond] from comment #10) > (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > > Botond, if you have some time, can you throw this into a build and > > run it by Gordon to see if he likes it? > > Will do! I showed Gordon the modified build. The overall feeling was that it's definitely an improvement, but it still feels suboptimal. We tested the same page, https://www.apple.com/ios/ios8/, on Fennec and on B2G (without the reduced opacity), and observed that it looks quite a bit better on Fennec than on B2G. Gordon said that if we could get the B2G version to look like the Fennec one, it would be great. It seems the next step is to figure out what is the cause of the difference in look between Fennec and B2G. A first step might be to try the two side-by-side on the same device (the comparison we made was Nexus 4 running B2G vs. Galaxy Nexus running Fennec).
Flags: needinfo?(botond)
(In reply to Botond Ballo [:botond] from comment #11) > We tested the same page, https://www.apple.com/ios/ios8/, on Fennec and on > B2G (without the reduced opacity), and observed that it looks quite a bit > better on Fennec than on B2G. Gordon said that if we could get the B2G > version to look like the Fennec one, it would be great. Huh, that's interesting. As far as I know they use exactly the same code.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #12) > (In reply to Botond Ballo [:botond] from comment #11) > > We tested the same page, https://www.apple.com/ios/ios8/, on Fennec and on > > B2G (without the reduced opacity), and observed that it looks quite a bit > > better on Fennec than on B2G. Gordon said that if we could get the B2G > > version to look like the Fennec one, it would be great. > > Huh, that's interesting. As far as I know they use exactly the same code. One suggestion that was brought up (I think by Jeff) was that the difference could be in the platform's graphics stack, for example in how fonts are anti-aliased / hinted.
Oh, it might also be that we use different fonts on Fennec than we do on B2G. Just loading the page normally the text looks different.
Disable high-res drawing to more easily see the low-res content. This may show blank in the initial view but scrolling around should make low-res content show up.
A fennec ARMv7 build with "low res only" can be found at people.mozilla.org/~kgupta/tmp/lowres.apk (it will show up as "Fennec kats" after installing).
The Flame has a 480px screen with a 1.5 HiDPI adjustment factor, so it is rendering 320 CSS pixels across. The Nexus 4 as a 768px screen with a 2.0 HiDPI adjustment factor, so it is rendering 384 CSS pixels across. They should be pretty close, but you can clearly see the text is much heavier on B2G.
Looks pretty much the same as the default b2g thing. I think this is all font-related.
For completeness this is what the high-res version looks like on the Flame.
After jumping through some hoops I managed to make Fennec use Fira Sans and render all the text in that font (rather than falling back to some Android font, which is what it was doing before). This is what it looks like in low-res. I don't know what's going on anymore!
Jonathan, do you know what fonts would get used for the text chunks at https://www.apple.com/ios/ios8/ in B2G and Fennec? The page specifies some fonts in their CSS and I'm not entirely sure if it will fall back to ClearSans on Fennec and/or FiraSans on B2G. Does the font-matching code try to find a better match if there is one installed on the device? In a nutshell the problem here is that when we draw the content on this page in low-res it looks significantly different in Fennec vs B2G and we're trying to figure out why. There are various screenshots attached to this bug - any thoughts you have on the topic would be helpful.
Flags: needinfo?(jfkthame)
Attachment #8436540 - Flags: feedback?(gbrander) → feedback-
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #25) > Jonathan, do you know what fonts would get used for the text chunks at > https://www.apple.com/ios/ios8/ in B2G and Fennec? The page specifies some > fonts in their CSS and I'm not entirely sure if it will fall back to > ClearSans on Fennec and/or FiraSans on B2G. Does the font-matching code try > to find a better match if there is one installed on the device? The CSS says font-family: "Lucida Grande","Lucida Sans Unicode","Helvetica","Arial","Verdana","sans-serif"; but none of the specifically named families there are available on B2G or Android (normally, anyhow), you'll get the default sans-serif face. So yes, I'd expect to see ClearSans on Fennec and Fira Sans on B2G. (BTW, I think their CSS is buggy: they almost certainly meant to specify the CSS generic value sans-serif, but instead it has the quoted family name "sans-serif". So instead of a generic fallback from CSS, we'll end up with the browser's default font - but that's sans-serif on Fennec and B2G anyway, so it won't make any difference to the result.) > In a nutshell the problem here is that when we draw the content on this page > in low-res it looks significantly different in Fennec vs B2G and we're > trying to figure out why. There are various screenshots attached to this bug > - any thoughts you have on the topic would be helpful. It looks different because they have different default fonts. The high-res screenshots show this, too: compare glyphs such as "I" and "g" to see that they're most definitely different. The other important difference here, besides different fonts, is different resolution. If you zoom in on the high-res screenshots, and compare the "What makes iOS8..." heading, you can see that the Fennec/Nexus4 version has about 50% higher pixel density than the Flame/B2G rendering. When it comes to the low-res screenshots, the resolution difference between the devices becomes much more obvious; in the Flame case, the font is being rendered at such low pixels-per-em that it really looks pretty bad. Again, if you compare the "What makes iOS8..." heading, which uses the same webfont in all cases, you can see how it's working with fewer pixels, and hence it's bound to end up with a rougher result.
Flags: needinfo?(jfkthame)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #19) > Created attachment 8437785 [details] > Low-res apple page on a Nexus4 with Fennec > > The Flame has a 480px screen with a 1.5 HiDPI adjustment factor, so it is > rendering 320 CSS pixels across. The Nexus 4 as a 768px screen with a 2.0 > HiDPI adjustment factor, so it is rendering 384 CSS pixels across. They > should be pretty close, but you can clearly see the text is much heavier on > B2G. Ah, here are the specs - I was wondering how the devices compared physically. So there's your answer, essentially. To render text that's the same size in CSS terms, the Nexus4 has more physical pixels available, and therefore it renders better. At full resolution, the difference may not be terribly noticeable, but once you scale things for low-res (what is it, 1/4?), the Flame is trying to rasterize Fira Sans at something like 8 pixels per em. It just isn't possible to produce an attractive, faithful rendition of the font at that size. Meanwhile, the Nexus4 has several more pixels to work with, and that makes a big difference.
Flags: needinfo?(oteo)
Thanks for the detailed comments, Jonathan! What you're saying makes sense. However when Botond and Gordon were looking at this (see comment 11), they were running B2G on a Nexus 4 and Fennec on a Galaxy Nexus, so B2G had the upper hand with resolution (Galaxy Nexus is 720px with a 2.0 DPI adjustment, for 360 CSS pixels). We don't have screenshots of that unfortunately but it sounded like B2G still didn't look quite as good as Fennec. Would that be entirely because of the difference in font?
I think it's quite likely, though hard to be sure without more direct comparison. It'd be interesting to try that comparison with the same font on both, though I realize it would take a bit of hackery to set that up. One thing that may well make a big difference, once we're rendering the fonts at such extremely low pixels-per-em, is that the Clear Sans we ship in Fennec is in TrueType format, while the Fira Sans in B2G is OpenType/CFF. This means they're using different outline description and hinting technologies, and being rasterized by entirely separate engines within FreeType. Both engines will be attempting to use grid-fitting and antialiasing to somehow produce an approximation of the glyph shapes within the handful of pixels available to them, but it's no surprise if they end up with quite different results. E.g. one may prioritize trying to maintain stroke weights, while another tries to maximize contrast; or any number of other tradeoffs that are involved in rendering a complex shape with too few pixels.
I got B2G running on my Nexus 4 and so finally have a comparable sets of screenshots: - attachment 8437785 [details] vs attachment 8440849 [details] (Fennec vs B2G in low-res on the same device). This eliminates the differences due to resolution and leaves only the differences due to font. - attachment 8438650 [details] vs attachment 8440849 [details] (Fennec vs B2G in low-res, with the same font, on the same device). B2G is still heavier.
If I'm reading the code correctly [1] then font hinting is currently disabled on B2G (and on Fennec!) and enabling it didn't seem to make a difference. I'm giving up on this bug unless anybody has any other ideas. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxAndroidPlatform.cpp?rev=e39cfafa8517#347
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #33) > - attachment 8438650 [details] vs attachment 8440849 [details] (Fennec vs > B2G in low-res, with the same font, on the same device). B2G is still > heavier. On these screenshots, the actual font rasterization looks really similar, it's just all much lighter on Fennec. Seems like it might be more of a graphics issue than a font issue at this point. Note that the text on that Apple page is specified as gray (#666), not black; and then you're adjusting its opacity as well (yes?). If the B2G compositor or graphics driver is handling the color and opacity differently from Fennec in some way, that could account for the difference. But I don't really know anything about that stuff.... (You did use the exact same Fira font files on both, I assume, so we're not seeing a .ttf vs .otf difference?)
(In reply to Jonathan Kew (:jfkthame) from comment #35) > and then you're adjusting > its opacity as well (yes?). The only screenshot with opacity adjusted is attachment 8437793 [details], all the rest have normal opacity. > (You did use the exact same Fira font files on both, I assume, so we're not > seeing a .ttf vs .otf difference?) Yeah. I might have done this wrong, though. Here's the exact patch I used: https://github.com/staktrace/gecko-dev/commit/9d9104baec0c5c73f430aa879ff31896b8c91312 I used the Fira files from https://github.com/mozilla/Fira/tree/master/ttf
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #36) > > (You did use the exact same Fira font files on both, I assume, so we're not > > seeing a .ttf vs .otf difference?) > > Yeah. I might have done this wrong, though. Here's the exact patch I used: > https://github.com/staktrace/gecko-dev/commit/ > 9d9104baec0c5c73f430aa879ff31896b8c91312 > > I used the Fira files from https://github.com/mozilla/Fira/tree/master/ttf Oh actually I definitely did that wrong. I should be using the Fira OTF files from the B2G build rather than the TTF files from the github repo. Oops.
I tried using this patch: https://github.com/staktrace/gecko-dev/commit/be0dd84be498bf351819bb497406955bf3ff4b15 to switch Fennec over to Fira Sans but it doesn't seem to be working. The lowercase 'g' letter doesn't look like the Fira version.
There's definitely a difference here, B2G is way heavier.
The difference in the TTF versions is much smaller.
Obsoleting all the old Nexus4 screenshots to reduce confusion
Attachment #8437785 - Attachment is obsolete: true
Attachment #8437796 - Attachment is obsolete: true
Attachment #8438650 - Attachment is obsolete: true
Attachment #8440848 - Attachment is obsolete: true
Attachment #8440849 - Attachment is obsolete: true
The high-res versions of the OTF font are much more similar than the low-res versions. So it seems like OTF just goes heavy when rendering in low-res whereas TTF does not.
So the upshot of all this is that on B2G, when Fira Sans OT is rendered low-res, it gets thicker. On Fennec that doesn't happen. Therefore, somewhere in the code we are treating Fennec and B2G differently, and it is impacting how OT fonts are rendered in low-res. Fixing that should make B2G look better in low-res.
Whiteboard: [summary in comment 45]
Jeff, do you know if the version of freetype we're using on Fennec is the same as on B2G. Also, do you know of any differences in font rendering flags between B2G and Fennec?
Flags: needinfo?(jmuizelaar)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #46) > Jeff, do you know if the version of freetype we're using on Fennec is the > same as on B2G. Also, do you know of any differences in font rendering flags > between B2G and Fennec? It should be the same version of freetype and I don't know of any differences off hand but I'll look.
Flags: needinfo?(jmuizelaar)
If we could get the unscaled low res screenshots that might make it easier to diagnose the issue. If that's too difficult, just disabling linear filtering might make be enough.
Also, Jonathan Kew might have a more useful answer to the question.
Flags: needinfo?(jfkthame)
Bug 829523 might be related perhaps.
Here are unscaled versions (I basically commented out the line at [1] which seemed to do the job). The B2G version still looks a hair heavier to me but it's hard to tell. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/TiledContentHost.cpp?rev=c4681bf6680c#428
Is the patch in attachment 8437740 [details] [diff] [review] correct for switching from linear to nearest-neighbour on B2G? I tried that and the B2G low-res screenshot looks exactly the same as before.
Flags: needinfo?(jmuizelaar)
I stepped through in gdb and as far as I can tell hinting is definitely disabled on B2G. RequiresLinearZoom() returns true and FontHintingEnabled() returns false. The various bits of code in gfxFT2FontList.cpp that deal with hinting all seem to be setting the right flags.
I'm at a dead end (again). I examined the screenshots in attachment 8442813 [details] and attachment 8442814 [details] again and the Fira Sans text seems identical in both, which makes me think it's not hinting. From stepping through with the debugger as well the hinting behaviour seems to be the same on both. Therefore the only possible culprit is the scaling method, and even if I line up the ifdefs so that the same scaling code is run on both Fennec and B2G I get the same behaviour. I might be missing something but I have no clue what.
Yes, my understanding is that - unless things have changed since last I looked - we have hinting disabled for this content on both Fennec and B2G, so that shouldn't be the issue. And the screenshots look like we're getting the same glyph bitmaps in both cases. I'm curious to know what happens if the text is pure black on white, rather than gray (the example has color #666, IIRC). Do we still end up with a similar difference in darkness between Fennec and B2G?
Flags: needinfo?(jfkthame)
Black text does appear to render the same on both. Does that point a finger at any particular part of the code?
POINT scaling looks the same on both. This is where I unconditionally set filter = gfx::Filter::POINT just before http://mxr.mozilla.org/mozilla-central/source/gfx/layers/opengl/CompositorOGL.cpp#1137
Attachment #8437790 - Attachment is obsolete: true
Based on the last few screenshots it looks like it's actually Fennec that is unnaturally light when scaled up using LINEAR filtering. This is clear if you compare attachment 8442146 [details] with attachment 8442978 [details], for example. The equivalent B2G screenshots (attachment 8442152 [details] vs attachment 8442982 [details]) show a difference in pixellation but not in darkness.
Component: Panning and Zooming → Graphics
Whiteboard: [summary in comment 45]
With the texture coords shifted by 0.5, Fennec suddenly gets much darker using the same LINEAR filtering as attachment 8442146 [details].
(In reply to Botond Ballo [:botond] (away until July 5) from comment #11) > I showed Gordon the modified build. The overall feeling was that it's > definitely an improvement, but it still feels suboptimal. > > We tested the same page, https://www.apple.com/ios/ios8/, on Fennec and on > B2G (without the reduced opacity), and observed that it looks quite a bit > better on Fennec than on B2G. Gordon said that if we could get the B2G > version to look like the Fennec one, it would be great. > > It seems the next step is to figure out what is the cause of the difference > in look between Fennec and B2G. A first step might be to try the two > side-by-side on the same device (the comparison we made was Nexus 4 running > B2G vs. Galaxy Nexus running Fennec). So it seems like the page tested here has exactly the right conditions to get rendered extra-light in Fennec's low-res tiles because of the combination of texture coordinates, font face, font engine, device resolution, and text color. On B2G it actually renders as expected. At any rate, using the apple page as a test site is bogus, so now we're back to square one with respect to making low-res look "good" in general. Gordon, do you have any suggestions beyond the opacity reduction I cooked up earlier for improving the look here?
Flags: needinfo?(jmuizelaar) → needinfo?(gbrander)
Discussed with Gordon during the UX/GFX meeting today. Given our lack of options here he's ok with just dialing down the opacity of the low-res content. We agreed to make it a pref value so Fennec doesn't see any changes, but we'll reduce it to 50% (to start with) on B2G.
Flags: needinfo?(gbrander)
Attachment #8436540 - Attachment is obsolete: true
Attachment #8437740 - Attachment is obsolete: true
Attachment #8443705 - Flags: review?(jmuizelaar)
Comment on attachment 8443705 [details] [diff] [review] Reduce opacity of low-res buffer on B2G Review of attachment 8443705 [details] [diff] [review]: ----------------------------------------------------------------- Sure, we can try this out to see how well it works.
Attachment #8443705 - Flags: review?(jmuizelaar) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
It works well in pages with a lot of text and apps like Settings and Contacts, but in webpages with a lot of images (ex. as.com) or in homescreen app, my feeling is that the low precision region became more noticeable.
No longer depends on: 1038214
Attached video Verify_Video_Flame.MP4
This issue has been verified successfully on Flame 2.0 & 2.1. See attachment: Verify_Video_Flame.MP4 Reproducing rate: 0/10 Flame v2.0 version: Gaia-Rev ead3b72a84512750bc5faff4e9e8faa1715c0d05 Gecko-Rev c715df57d1d1593ede48140ebc88e101f8c3f7da Build-ID 20141208050313 Version 32.0 Device-Name jrdhz72_w_ff FW-Release 4.4.2 Flame v2.1 version: Gaia-Rev 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a Build-ID 20141205001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141205.035305 FW-Date Fri Dec 5 03:53:16 EST 2014 Bootloader L1TC00011880
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: