flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <devudes...@gmail.com>
Subject Re: [FalconJS] concepts
Date Fri, 30 Nov 2012 11:00:51 GMT
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 :)


On 11/30/2012 10:40 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <aharui@adobe.com> wrote:
>> On 11/29/12 3:31 AM, "Frank Wienberg" <frank@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...

View raw message