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

On Sat, Jun 1, 2013 at 3:09 AM, Ali Juma <ajuma@chromium.org> wrote:

> 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.
>

OK, but the other constraints I mentioned (that you cropped) still apply.

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.
>

If the transition duration is not much longer than the time required to
paint the expensive content, that sounds bad no matter what you do, since
delaying the start of the transition that much will make the UI appear
unresponsive. Right?

Is it important to notify the Web page when "the content is ready"? I
thought we were going to do this entirely in the engine?


> -- 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.
>

I meant that the browser would do a low-fi rendering of the content
automatically, without Web authors doing anything special.

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.
>

I agree with that.

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"