Re: Adding a paint event to HTMLElement to support Web Components / Shadow DOM

On Tue, May 8, 2012 at 5:56 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/8/12 8:30 PM, Gregg Tavares (勤) wrote:
>
>> AFAICT the resize event only fires on window.
>>
>
> There have been proposals over the years to change that.
>
>
>  Imagine a relatively heavy to repaint WebComponent like one that draws
>> an representation of an audio wave. If that component is hidden behind
>> some other component it would be nice if it didn't re-draw itself.
>>
>
> This seems like a use case for requestAnimationFrame's second argument,
> and browser quality-of-implementation issues.


I don't think I understand how requestAnimationFrame would work here. Maybe
my example was poor. I'm not suggesting a live constantly updating audio
wave. Instead I'm suggesting a static WebComponent that is heavy to render.
For example the wave display in an audio editing tool. Let's say I had an
app that displayed several audio tracks, some of those tracks are scrolled
off the page. (like this http://www.newfreedownloads.com/imgs/17189-w520.jpg)
The tracks components are set to 100% width so that sizing the window ends
up re-sizing all the components, even the components off the screen.
Ideally only those components that are on the screen will get a paint event
since if say 80% of the components are off the screen and they are heavy to
update it would be nice if they weren't updated until the user brings them
on the screen by scrolling them on.


>
>
>  Does a 'paint' event make sense?
>>
>
> Possibly, depending on how it's defined; actually running arbitrary script
> during painting is pretty undesirable (e.g. ideally painting happens on a
> totally separate thread from script, and having to synchronize them is not
> particularly ideal).
>
> -Boris
>
>
>