> perhaps that can be optimized without changing the spec.
Perhaps UAs can be optimized for this rather common design pattern, and if so,
they certainly should be. And even then, for some kinds of the burgeoning
multi-screen apps, such as those on VR, watches, and Cast-like products, having
a codified dumb pixel box mode might be the path of least resistance for the
platform.
I am not a browser developer, I am a Web developer, but it stands to reason
that (as stated in the OP) there may at least be a fruitful memory savings, if
not other fast-path cheats that can be enabled in a more predictable rendering
environment.
On the memory front, this could be especially useful when sharing space with
the 30+ tabs that some users are known to spawn–not a great situation for an
Unreal Engine 4 game, or even for users who open taskman to obsess over and
decry their favorite browser's memory use.
> On Jul 7, 2014, at 5:17 PM, Justin Novosad <ju...@google.com> wrote:
>
> Do you have any data to back the proposal? For example, how much overhead do
> you expect this to save compared to a document that contains just a
> full-screen canvas? Is the HTML parsing, style calculation and DOM layout
> overhead really that high for a document that has nothing but a canvas
> element in it? If it is, perhaps that can be optimized without changing the
> spec.
>
>
>> On Mon, Jul 7, 2014 at 4:35 PM, Brian Blakely <anewpage.me...@gmail.com>
>> wrote:
>> Floating a concept for a document mode which eschews CSS and the DOM
>> to enable a more jank-free Canvas surface.
>>
>> Depending on how this allows for optimization, might be used well for
>> games, VR, wearables, and ultra-portable or high-performance apps.
>> Probably most beneficial to memory usage and first paint time. Would
>> appreciate if some vendor engineers who might be reading could chime
>> in on this point.
>>
>> Strawman:
>>
>> Document only contains <!doctype canvas-[2d|3d]> and script elements.
>> Everything else is ignored. "document" object is gone.
>>
>> A Canvas drawing surface consumes the entire viewport. It always has
>> an opaque backing store, same as specifying getContext('2d', { alpha:
>> false }).
>>
>> UA provides:
>> * A host object representing surface's CanvasRenderingContext2D or
>> WebGLRenderingContext (depending on specified doctype).
>>
>> * In lieu of DOM, an API for creating offscreen canvases (actually,
>> this abstraction should probably exist anyway). This might live on
>> the Context host obj, which may open a beneficial performance
>> relationship between onscreen canvas and offscreen "children".
>
