Hi Ashley,
With the budding of Canvas 2D and WebGL UI frameworks, I believe that, in a
couple years' time, the role of CSS in the cases I described will diminish
drastically. A lot of this was kind of waiting for Apple to give the OK before
people began committing their hearts to WebGL.
> On Jul 7, 2014, at 5:17 PM, Ashley Gullen <ash...@scirra.com> wrote:
>
> 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.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".
>
