When I was thinking about how to make distinction between canvas and DOM
based display list output, I thought of letting developer choose on
compile time.
But I really like your solution with casheAsBitmap. On top of graphics
API I was planing to add another feature casheStyle("id") and what it
does it will store
css properties that you can reuse by graphics.getStyle("id") within
other sprites/shapes. It will minimise overbloatnes of custom style per div.
I guess for stuff like flex application html DOM will be more desirable
solution, but things like simulating Bitmap or interactive Charts,
Canvas still is must have.
I know there are some issues with transform on DOM elements but where is
a problem there is a solution.
What I can tell, you seems not to pay attention to that part yet, since
lots of matrix transformations are not implemented yet.
However, flex apps don't rotate/skew/scale too much :)
Dan
On 11/30/2012 10:40 AM, Frank Wienberg wrote:
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...
