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

Re: [whatwg] Canvas-Only Document Type

From: Ashley Gullen <ashley@scirra.com>
Date: Mon, 7 Jul 2014 22:17:59 +0100
Message-ID: <CAABs73hj+3rL2mTo8LC3eWqw9xX=KA9LYOxrNgO02exf1ie-6w@mail.gmail.com>
To: Brian Blakely <anewpage.media@gmail.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Having developed a major HTML5 game engine, and given this appears to be
aimed at a gaming use case, I feel qualified to offer my opinion: I'm not
sure this is a good idea.

Despite being 99% canvas and javascript, we use CSS to implement some
useful scaling modes (like letterbox fullscreen). We also use the DOM for
many useful features, such as form controls, divs, Twitter or Facebook
buttons and so on, which are positioned over the canvas. In particular text
inputs are useful for things like name entry or logins even for games, and
are typically difficult and error-prone to reimplement in only canvas and
javascript.

Is there any evidence that such a mode would actually improve performance?
Are there benchmarks indicating the existence of a DOM, even if inert,
harms performance in any way?

Ashley Gullen
Scirra.com



On 7 July 2014 21:35, 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 21:18:29 UTC

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