Re: Properties of Custom Paint

<sorry for duplicate, sent from wrong account :( >

Hey Dean,

I would suggest adding, or rewording the footgun item, to have something
> more about performance. Setting a tainted flag to disallow readback helps
> some performance issues, but not all of them.
>
> Given the current storyline on how the Web isn't performant enough
> compared to native, I think we should be especially mindful about adding
> API that could cause painting and rendering to stutter. Maybe there should
> be consideration for whether a callback that runs too long can block
> painting (e.g. the developer could choose that they prefer the content from
> the previous render in this case).
>


Yeah we tried to capture this in - "Able to mark handlers as optional" (is
this the performance that you were concerned about, e.g. the browser being
able to drop callbacks if it doesn't think it has enough time/bad actors?),
but there was some debate around this. I'd love to get other peoples
thoughts if this is required or not.

There are a few different axis to consider here I believe.
1) The behavior from the developers point of view should be predictable.

If a custom paint behavior is absolutely required for a UI, then it should
always be painted. However, you could imagine that there might be lots of
effects that the paint code could drop, if not required. For example a
really complex to paint box-shadow might be in this category.
What concerns me about dropping callbacks is that there isn't anything in
CSS today which won't paint, under system load.

2) It's already possible for bad actors.

I don't see a difference in the bad actor case for custom paint vs. main
thread. You can have a bad actor on the main thread (doing canvas painting)
and block paint/frame for an indeterminate amount of time.

Thanks,

Ian


On Wed, May 20, 2015 at 4:20 PM, Dean Jackson <dino@apple.com> wrote:

>
> On 20 May 2015, at 7:00 am, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> On Wed, May 20, 2015 at 2:25 AM, Ian Kilpatrick <ikilpatrick@chromium.org>
> wrote:
>
>> We wanted to start kicking off more discussions on the mailing list. As a
>> starting point Shane & I sat down and wrote up what we think are the
>> desirable properties of custom paint.
>>
>> See https://gist.github.com/bfgeek/758b54a1cab65dff9d69
>>
>> Feel free to respond here, or directly on the gist.
>>
>
> I like those, FWIW.
>
>
> Me too.
>
> I would suggest adding, or rewording the footgun item, to have something
> more about performance. Setting a tainted flag to disallow readback helps
> some performance issues, but not all of them.
>
> Given the current storyline on how the Web isn't performant enough
> compared to native, I think we should be especially mindful about adding
> API that could cause painting and rendering to stutter. Maybe there should
> be consideration for whether a callback that runs too long can block
> painting (e.g. the developer could choose that they prefer the content from
> the previous render in this case).
>
> As I've said to Shane and Ian offline, I think that a variant on the
> element() feature can address many of the requirements for custom paint
> with a few API modifications (allowing it to be used in more places, in
> addition to default rendering, responding to layout updates, etc). We've
> found -webkit-canvas to be especially useful in this manner (we use it for
> the custom rendering of our scrubber bar in media controls).
>
> Dean
>
>
>
>