Closed
Bug 1020778
Opened 10 years ago
Closed 10 years ago
Alpha scrolling in Contacts is not working fine
Categories
(Core :: Graphics, defect)
Tracking
()
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
Reporter | ||
Updated•10 years ago
|
blocking-b2g: --- → 2.0?
Comment 1•10 years ago
|
||
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?
Keywords: regression,
regressionwindow-wanted
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
QA Contact: pcheng
Comment 2•10 years ago
|
||
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.
Keywords: regressionwindow-wanted
Comment 3•10 years ago
|
||
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
Comment 4•10 years ago
|
||
(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.
Comment 5•10 years ago
|
||
Yes, we're working with UX on this.
Assignee | ||
Comment 7•10 years ago
|
||
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)
Comment 8•10 years ago
|
||
(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.
Assignee | ||
Comment 9•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
(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!
Comment 11•10 years ago
|
||
(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)
Assignee | ||
Comment 12•10 years ago
|
||
(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.
Comment 13•10 years ago
|
||
(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.
Assignee | ||
Comment 14•10 years ago
|
||
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.
Assignee | ||
Comment 15•10 years ago
|
||
Assignee | ||
Comment 16•10 years ago
|
||
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.
Assignee | ||
Comment 17•10 years ago
|
||
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).
Assignee | ||
Comment 18•10 years ago
|
||
Assignee | ||
Comment 19•10 years ago
|
||
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.
Assignee | ||
Comment 20•10 years ago
|
||
Looks pretty much the same as the default b2g thing. I think this is all font-related.
Assignee | ||
Comment 21•10 years ago
|
||
Assignee | ||
Comment 22•10 years ago
|
||
For completeness this is what the high-res version looks like on the Flame.
Assignee | ||
Comment 23•10 years ago
|
||
Assignee | ||
Comment 24•10 years ago
|
||
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!
Assignee | ||
Comment 25•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Attachment #8436540 -
Flags: feedback?(gbrander) → feedback-
Comment 26•10 years ago
|
||
(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)
Comment 27•10 years ago
|
||
(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.
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(oteo)
Assignee | ||
Comment 28•10 years ago
|
||
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?
Comment 29•10 years ago
|
||
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.
Comment 30•10 years ago
|
||
Flags: in-moztrap+
Assignee | ||
Comment 31•10 years ago
|
||
Assignee | ||
Comment 32•10 years ago
|
||
Assignee | ||
Comment 33•10 years ago
|
||
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.
Assignee | ||
Comment 34•10 years ago
|
||
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
Comment 35•10 years ago
|
||
(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?)
Assignee | ||
Comment 36•10 years ago
|
||
(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
Assignee | ||
Comment 37•10 years ago
|
||
(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.
Assignee | ||
Comment 38•10 years ago
|
||
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.
Assignee | ||
Comment 39•10 years ago
|
||
Assignee | ||
Comment 40•10 years ago
|
||
There's definitely a difference here, B2G is way heavier.
Assignee | ||
Comment 41•10 years ago
|
||
Assignee | ||
Comment 42•10 years ago
|
||
The difference in the TTF versions is much smaller.
Assignee | ||
Comment 43•10 years ago
|
||
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
Assignee | ||
Comment 44•10 years ago
|
||
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.
Assignee | ||
Comment 45•10 years ago
|
||
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]
Assignee | ||
Comment 46•10 years ago
|
||
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)
Comment 47•10 years ago
|
||
(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)
Comment 48•10 years ago
|
||
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.
Comment 49•10 years ago
|
||
Also, Jonathan Kew might have a more useful answer to the question.
Flags: needinfo?(jfkthame)
Comment 50•10 years ago
|
||
Bug 829523 might be related perhaps.
Assignee | ||
Comment 51•10 years ago
|
||
Assignee | ||
Comment 52•10 years ago
|
||
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
Assignee | ||
Comment 53•10 years ago
|
||
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)
Assignee | ||
Comment 54•10 years ago
|
||
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.
Assignee | ||
Comment 55•10 years ago
|
||
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.
Comment 56•10 years ago
|
||
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)
Assignee | ||
Comment 57•10 years ago
|
||
Assignee | ||
Comment 58•10 years ago
|
||
Black text does appear to render the same on both. Does that point a finger at any particular part of the code?
Assignee | ||
Comment 59•10 years ago
|
||
Assignee | ||
Comment 60•10 years ago
|
||
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
Assignee | ||
Comment 61•10 years ago
|
||
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
Assignee | ||
Updated•10 years ago
|
Whiteboard: [summary in comment 45]
Assignee | ||
Comment 62•10 years ago
|
||
With the texture coords shifted by 0.5, Fennec suddenly gets much darker using the same LINEAR filtering as attachment 8442146 [details].
Assignee | ||
Comment 63•10 years ago
|
||
(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)
Assignee | ||
Comment 64•10 years ago
|
||
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)
Assignee | ||
Comment 65•10 years ago
|
||
Attachment #8436540 -
Attachment is obsolete: true
Attachment #8437740 -
Attachment is obsolete: true
Attachment #8443705 -
Flags: review?(jmuizelaar)
Comment 66•10 years ago
|
||
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+
Assignee | ||
Comment 67•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Comment 70•10 years ago
|
||
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.
Comment 71•10 years ago
|
||
status-b2g-v2.0:
--- → fixed
status-b2g-v2.1:
--- → fixed
status-firefox31:
--- → wontfix
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
Comment 72•10 years ago
|
||
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
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•