Re: [css-display]? Compositing, expensive things, and laziness

On Thu, May 30, 2013 at 7:40 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> I'm unenthusiastic about adding a feature with a very narrow range of
> utility. In this case the range is very narrow: a page with complex content
> coming into view, running on an implementation that supports
> off-main-thread-painting but not enough parallelism to paint the content
> quickly
>

This is not all that unusual on mobile, where painting can be notoriously
slow, spanning multiple vsync intervals. Without a way to mark content as
"optional", the only choices are to checkerboard or to drop frames while
painting happens.


Here are some alternatives that you've probably considered but I'd like to
> hear more about:
> -- If you use a heuristic to suppress rendering at the beginning of an
> opacity transition when the opacity values are small, does that look bad?
>

This approach seems to require web authors to guess how long content is
going to take to paint, so that they create transitions with sufficiently
long durations that the time during which the opacity value is small
matches the time it will take to paint. But paint time is going to vary
based on device and on different browsers, and will also vary over time as
implementations evolve. So web authors would either need to have a table
tracking paint time across different configurations, or hard-code a large
value that would be an overestimate on powerful devices, or hard-code a
small value that would be an underestimate on low-end devices. We want to
eliminate the need for guesswork, by sending a notification when the
content is ready.


-- What if you just fudge the shape of the opacity transition function in
> the compositor so the painting of expensive content can be automatically
> delayed a little with the rest of the transition sped up to compensate? I
> don't know what is expensive about the content in the cases you have in
> mind, but I presume some heuristics could detect it.
>

The problem with detecting expensive content and automatically treating it
differently is that whether it's reasonable to treat it differently really
depends on understanding how the expensive content relates to other content
on the page. For example, if we have a slideshow where slides and captions
are fading in and out, and slides are expensive (say they take 100 ms to
paint) but captions are cheap, we wouldn't want to have the captions and
slides animate out-of-sync. On the other hand, if we have an
infinite-scroll newsfeed where each entry added to the newsfeed as the user
scrolls is expensive to paint, and where there's some reasonable
already-painted content underneath the new content, it's reasonable to
postpone drawing or animating newly added stories until they are painted,
while still keeping the page responsive in the meanwhile. The best way to
figure out whether it's appropriate for content to be treated this way is
to give web authors the power to tell us.


-- What about other techniques to speed up the initial rendering of the
> content in exchange for reduced quality when the opacity values are low
> enough the content is barely visible anyway?
>

This still seems to require web authors to guess how long painting will
take, so that the low-res content is ready when opacity values are high
enough that the content is barely visible, and so that high-res content is
ready once the content is more-than-barely visible.

The main alternative approach we considered was to treat opacity 0 as a
signal that content was optional for painting (this is non-controversial,
since it has no effect on what's displayed on the screen), and to treat
animations from opacity 0 to opacity 0 in a special way (this is the
controversial part): we would delay starting these animations until the
content was painted, but we would allow everything else on the page to
carry on as usual in the meanwhile (and, in particular, we would allow
other animations to start even if they were added later than the opacity 0
to opacity 0 animation). With this approach, the animationstart event for
the opacity 0 to opacity 0 animation could be treated as a notification
that the content was painted. Since this approach treats a specific
animation in a special way, it seems more hacky than having explicit syntax
for marking content as optional and for receiving a notification that
optional content is ready.

-Ali