[whatwg] Please unsubscribe me
Sent from my iPhone
[whatwg] Canvas-Only Document Type
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.
Re: [whatwg] Canvas-Only Document Type
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.
Re: [whatwg] Canvas-Only Document Type
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.
Re: [whatwg] Canvas-Only Document Type
Has anyone considered the accessibility implications of this? IIUC accessibility for canvas is provided through extra dom elements. So, this would defeat that purpose. Silvia. On Tue, Jul 8, 2014 at 8:39 AM, Brian M. Blakely anewpage.me...@gmail.com wrote: 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.
Re: [whatwg] Canvas-Only Document Type
The use cases involved are mostly intended for 60fps high-load graphics, so the kind of a11y conditions served by the DOM (screen readers) aren't as helpful in these apps. I don't think the DOM makes videogames more accessible. The Web Platform doesn't serve that case well; it isn't something this is trying to solve. On Jul 7, 2014, at 6:54 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Has anyone considered the accessibility implications of this? IIUC accessibility for canvas is provided through extra dom elements. So, this would defeat that purpose. Silvia. On Tue, Jul 8, 2014 at 8:39 AM, Brian M. Blakely anewpage.me...@gmail.com wrote: 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.
Re: [whatwg] Canvas-Only Document Type
Brian M. Blakely anewpage.me...@gmail.com writes: The use cases involved are mostly intended for 60fps high-load graphics, so the kind of a11y conditions served by the DOM (screen readers) aren't as helpful in these apps. I don't think the DOM makes videogames more accessible. The Web Platform doesn't serve that case well; it isn't something this is trying to solve. I think no one should ever optimize for inaccessible web content. In case you think otherwise: Would you elaborate why your wish to display “60fps high-load graphics” on the web outweighs the needs of people with old or non widely used hardware or software, people with disabilities, software that has no optical sensory input (e.g. web spiders) and all those of us users who want to zoom or select text? Consider the following: If web content is not accessible by default, only a privileged class of users will be able to see and use it. We had that scenario already when “web” developers used Flash for everything. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Canvas-Only Document Type
If you want jank-free canvas rendering, you probably really want WebGL drawing from a Worker. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.