Based on testing, it seems like images may not get painted too soon if main thread is busy. Even if RefreshDriver ticks, layout may not have gotten the notification from imglib that something can be painted... assuming I'm reading the code right.

We believe this impacts perceived performance during pageload and would like this to get high priority.

So the notifications are pending on the main thread but other things take priority? Maybe we could add a phase to the refresh driver to fire any pending image notifications.

Main thread has 4 different queues, of which runnables in high priority queue (vsync basically) are
handled before normal priority runnables. And if normal priority queue is rather long, it may take some
before runnables from imglib's thread(s) are handled in the main thread.

(But one thing to look at here too, or in some other bug, is what triggers decoding. Does it happen soon enough?)

(Simple testcase becomes easier to write if bug 1506376 is fixed)

(In reply to Olli Pettay [:smaug] from comment #3)

(But one thing to look at here too, or in some other bug, is what triggers
decoding. Does it happen soon enough?)

Yeah, that is something to look into too, but it is generally a top concern of mine when writing code, reviewing code, or looking into testcases etc, so hopefully we are in pretty good shape there.

Comment on attachment 9036213 [details]
a testcase to be used with bug 1506376

Bah, sorry, this isn't particularly good example, since decoder thread doesn't even get the request soon enough. Need to tweak this.

Based on profiler this is better. We decode early, but don't paint the image soon. Looks like the test is a bit racy, since in some cases we manage to paint img before handling postMessages.
https://perfht.ml/2soJmyG is what I usually see.

If bug 1524006 gets fixed, that might be useful too.

(wip https://hg.mozilla.org/try/rev/006df9db90924aea100554a3feaf84afc1f543f3 That patch contains also other stuff and imglib part may have issues, but it does fix the test case)

IMAGE_DECODE_ON_DRAW_LATENCY telemetry can be used here to see how this helps.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ca325ac15c847e49228c69e5878072ad03457cff

With medium high queue(bug 524006), this bug (bug 1519567) and high prio DidComposite (bug 1506376),
IMAGE_DECODE_ON_DRAW_LATENCY goes from 4260550μs to 21416μs when running the testcase.
Those numbers of course vary a lot, but give a good hint.

These patches make -loads- of difference on Facebook and various other sites, we should consider it a high priority to get this shipped in my opinion.

Looks like someone run clang-format on imglib, so removing clang-format changes from the patch.

remote: Follow the progress of your build on Treeherder:
remote: https://treeherder.mozilla.org/#/jobs?repo=try&revision=efecded1539a7742febb5716c14daabf189d9c2b

https://hg.mozilla.org/mozilla-central/rev/339a3c5969e1