Closed Bug 1140019 Opened 6 years ago Closed 6 years ago

eideticker taskjs regression Tue, 03 Mar 2015

Categories

(Firefox for Android :: Toolbar, defect)

Product:
Firefox for Android
Component:
Toolbar
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
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)
tracking-fennec: --- → ?
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)
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)
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: 6 years ago
Resolution: --- → INVALID
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.
Would it be possible to set it to something like 0? Or even just a solid color like purple?
Flags: needinfo?(bugmail.mozilla)
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)
(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
tracking-fennec: ? → -
You need to log in before you can comment on or make changes to this bug.