Closed
Bug 1140019
Opened 10 years ago
Closed 10 years ago
eideticker taskjs regression Tue, 03 Mar 2015
Categories
(Firefox for Android Graveyard :: Toolbar, defect)
Tracking
(fennec-)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
fennec | - | --- |
People
(Reporter: wlach, Unassigned)
References
Details
(Whiteboard: [eideticker-regression])
Looks like the taskjs benchmark (already regressed from where it was a few years ago) has regressed further:
http://eideticker.mozilla.org/#/android/samsung-gn/mozilla-central/taskjs/checkerboard/30
I suspect bug 1137203 is the culprit. The regression went away when the work was backed out, now it's back again.
I'm not sure what should be done here, if anything. I'll start by NI'ing kats
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Updated•10 years ago
|
tracking-fennec: --- → ?
Comment 1•10 years ago
|
||
From what I can tell from the videos it looks like progressive painting got disabled, so it draws the entire screen at once rather than tile-by-tile. However when I load taskjs.org on my device locally and scroll I still see tile-by-tile updates so I'm wondering if this is specific to the harness. Are there any non-default prefs set in the Eideticker harness?
Flags: needinfo?(bugmail.mozilla) → needinfo?(wlachance)
Comment 2•10 years ago
|
||
Actually it makes sense - Eideticker disables low-precision painting, which means the critical displayport is always going to be empty, so we won't draw progressively. This is expected behaviour now - it was done intentionally because it doesn't make sense to draw progressively unless we also have low-precision enabled. On all production platforms where we do progressive, we also have low-precision. I guess the Eideticker harness is not representative of production environments in that respect.
Flags: needinfo?(wlachance)
Reporter | ||
Comment 3•10 years ago
|
||
Yep, we never updated eideticker to detect low-precision paints. I guess this means all eideticker's checkerboarding tests are no longer useful, at least until we fix bug 857644.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Comment 4•10 years ago
|
||
Something else to consider is we now have a pref to control the opacity of low-precision regions. So if you set layers.low-precision-opacity to something low like 0.1 the low-precision content will be very faint and mostly just solid color. If you set to high (1.0) the low-precision content will be solid. Dialing that down to something very low might make it easier to detect and ignore.
Reporter | ||
Comment 5•10 years ago
|
||
Would it be possible to set it to something like 0? Or even just a solid color like purple?
Flags: needinfo?(bugmail.mozilla)
Comment 6•10 years ago
|
||
You should be able to set it to 0, yes. However you can't set it to a specific color. If it's 0 it will just end up the background color (or whatever gecko thinks the background color should be).
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 7•10 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6)
> You should be able to set it to 0, yes. However you can't set it to a
> specific color. If it's 0 it will just end up the background color (or
> whatever gecko thinks the background color should be).
That's exactly the behaviour we want actually. :) I updated the configuration in eideticker, new test runs should be using the configuration.
https://github.com/mozilla/eideticker/commit/1a5c96ccec080eb1e5db70af8f6a2d1cf3b27d2a
Resolution: INVALID → FIXED
Comment 8•10 years ago
|
||
\o/
Updated•10 years ago
|
tracking-fennec: ? → -
Updated•5 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•