On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <aha...@adobe.com> wrote:
> > On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote: > > > Primarily, I also map DOs to DOM elements! > > > > Greetings > > -Frank- > Just curious, but how does this mapping work? How many DOM objects are > being created and what does the drawing, SVG? > > Usually only one DOM object, but that can be different in each DisplayObject subclass. The actual drawing (flash.display.Graphics) is always done through a canvas (which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite consists of a <div> container with a <canvas> for rendering and more DOM elements for all contained child-DOs. Because in typical gaming scenarios, this approach led to a lot of canvases being created and turned out to be slow and memory-consuming, I implemented a mode where a complete DisplayList-subtree (well, the thing called DisplayList actually is a tree!) is rendered into a single canvas. This is the approach taken by DartFlash and works extremely well for games and animations where almost all DOs are graphics or simple text, but is not so good for interactive components like TextField, where you would have to emulate all the interactive behavior on a low-level basis (blinking cursor etc.). Since it seems none of the two solutions is always preferable, I now let the developer decide. Setting "cacheAsBitmap" to true on a DO-Container activates canvas mode for that DL-subtree, but other parts of the DL can still use DOM-mode, so you can mix-and-match graphics and interactive parts of your UI. Note however that the DOM-mode supports less Flash features and has several known bugs concerning scaling and rotation (it is really tough to map these on CSS3 transforms and it turned out to be much easier when using canvas 2D API). It might even be that after the canvas-refactoring, DOM-mode work worse than before...
