W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Canvas-Only Document Type

From: Brian M. Blakely <anewpage.media@gmail.com>
Date: Mon, 7 Jul 2014 18:58:06 -0400
Message-Id: <96BABDC5-D20F-464F-AFE4-E822CC9CC2AD@gmail.com>
To: Justin Novosad <junov@google.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
> 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 <junov@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.media@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".
Received on Monday, 7 July 2014 22:58:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC