(In reply to comment #0) > To simplify its shadow support (on Bug 94307), this change will eliminate conditional shadow tree creation of media elements > and always build it on the instantiation time. > Since media elements allocates media buffer and codec resources, an impact on the memory footprint of this change is negligible. A media element does *not* always allocate media or codec buffers, this only happens when/if media data is loaded and decoded.

> A media element does *not* always allocate media or codec buffers, this only happens when/if media data is loaded and decoded. True. My understanding is that properly used media elements will consume these memory eventually. Is there any patterns which activates only small fraction of these elements in the page? If so, such cases should be taken into account.

I found that most of MediaControls subclasses depends on page()->theme() object, which isn't available for head-less Document object (like one from XHR) So it isn't simple to ensure the existence of media control object which is the major part of the media element shadow. I'd explore other approach.

(In reply to comment #2) > My understanding is that properly used media elements will > consume these memory eventually. > Is there any patterns which activates only small fraction of these elements > in the page? If so, such cases should be taken into account. Again, not necessarily. A media element with a valid 'src' attribute and 'preload=none' will not load any media data until 'preload' changes or the element is told to load explicitly or implicitly (eg. by changing currentTime or play()). It is not uncommon for a page to have one or more a media elements that never load media data because the user never triggers playback.

(In reply to comment #4) > (In reply to comment #2) > > My understanding is that properly used media elements will > > consume these memory eventually. > > Is there any patterns which activates only small fraction of these elements > > in the page? If so, such cases should be taken into account. > > Again, not necessarily. A media element with a valid 'src' attribute and 'preload=none' will not load any media data until 'preload' changes or the element is told to load explicitly or implicitly (eg. by changing currentTime or play()). > > It is not uncommon for a page to have one or more a media elements that never load media data because the user never triggers playback. What do you think about tying the creation of the <webkit-media-surface>--a hypothetical, non-web-exposed HTML element that represents the actual rectangle where the pixels are rendered--to the actual moment when we have data to render? We still create a shadow root, but not populate it with stuff until we need to.

(In reply to comment #5) > What do you think about tying the creation of the <webkit-media-surface>--a hypothetical, non-web-exposed HTML element that represents the actual rectangle where the pixels are rendered--to the actual moment when we have data to render? > > We still create a shadow root, but not populate it with stuff until we need to. That might work. What will we use as the trigger to create the <webkit-media-surface>? setDisplayMode(Video) could work if we only care about a <video> element, but what an <audio> element with a background image? Do we need the pseudo-element for a <video> element with @poster?

(In reply to comment #6) > (In reply to comment #5) > > What do you think about tying the creation of the <webkit-media-surface>--a hypothetical, non-web-exposed HTML element that represents the actual rectangle where the pixels are rendered--to the actual moment when we have data to render? > > > > We still create a shadow root, but not populate it with stuff until we need to. > > That might work. What will we use as the trigger to create the <webkit-media-surface>? setDisplayMode(Video) could work if we only care about a <video> element, but what an <audio> element with a background image? Do we need the pseudo-element for a <video> element with @poster? One approach what I'm thinking is less drastic. - media elements always have shadow tree + <webkit-media-surface> - they have media controls only when it is required. This introduces two extra nodes (ShadowRoot and <webkit-media-surface>) but the basic behavior won't change.

(In reply to comment #7) > > One approach what I'm thinking is less drastic. > - media elements always have shadow tree + <webkit-media-surface> > - they have media controls only when it is required. > > This introduces two extra nodes (ShadowRoot and <webkit-media-surface>) but > the basic behavior won't change. This sounds exactly like the plan outlined in the bug description, where the rational was that a media element always allocates media buffer and codec resources. We know that is not always true, is the impact on memory footprint no longer a concern?

(In reply to comment #8) > > This sounds exactly like the plan outlined in the bug description, where the rational was that a media element always allocates media buffer and codec resources. We know that is not always true, is the impact on memory footprint no longer a concern? Memory footprint should always be a concern! :) Morrita-san, is it feasible to lazily instantiate shadow root when: a) it's needed by the element b) an author shadow is added to element?

> > This sounds exactly like the plan outlined in the bug description, where the rational was that a media element always allocates media buffer and codec resources. We know that is not always true, is the impact on memory footprint no longer a concern? > > Memory footprint should always be a concern! :) Morrita-san, is it feasible to lazily instantiate shadow root when: > a) it's needed by the element > b) an author shadow is added to element? What the bug description says is worse ... But anyway, I'll try that lazy instantiation approach. Once it works, the bug 94307 will be also resolved.