You are right that Canvas is “paint and forget”, but EaselJS managed to make it act like a display list by keeping track of a virtual structure. We’re already doing that with FlexJS with ALL browser content, and canvas is not different.
The concept is not very complicated. We just need to have strategic points where we trigger a screen draw. I believe EaselJS requires the user to initiate the draw, but there’s no reason why we can’t have a delayed draw that’s initiated each time a property is written. There can be a delay of maybe 100 ms and all commands within that delay are added to a queue and the queue can be triggered earlier if there’s a reason to do so (i.e. validateNow() or similar). Events require fancy footwork, but they are doable as well. I think the idea is that you listen to events on the canvas (or window) as a whole and direct the event to the appropriate “object” based on position. On Jul 24, 2016, at 9:27 PM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > Sorry, I am jumping into this slightly old thread. Just catching up with > all the emails :-) > > A bit of a background to the Graphics package in FlexJS: The goal was to > make it possible to write MXMLG/FXG syntax in FlexJS and have it compiled > to SVG for the HTML/JS implementation. It was not originally intended to > be swappable with Canvas drawing API. > > The biggest reason for this is that SVG is retain mode whereas Canvas is > paint and forget mode. Which means that after drawing on the screen, it is > possible to target the individual drawing elements and manipulate them. > With MXML this is easily possible to do this: > > > <Rect id="myRect" x="0" y="0" width="100" height="100"> > <fill> > <SolidColorFill id="myColorFill" color="FF0000" /> > </fill> > </Rect> > > Elsewhere, in code, you could do things like: > > myRect.height = 500; > myColorFill.color = #00FF00; > > The way the current graphics package in FlexJS is implemented, this code > will work fine in transpiled SVG/JS as well. > > I don't think that this will be easily doable with a Canvas drawing API. > The entire canvas is one DOM element. Anything drawn inside Canvas cannot > be (easily) accessible. Unless you want to setup everything and draw it > again. > > Even then, you wont be able to target individual elements with mouse > events. Applications like Charts, for example have the need to be > interactive. You want to be able to enlarge a circle when you mouseover, > etc. With a Canvas implementation these kind of things are not possible. > > As you mentioned in another email, Canvas has a lot of similarities to > Flash's drawing API, but the FlexJS graphics package is an abstraction of > the Flash drawing api which provides a set of SVG like drawing elements. > > Thanks, > Om > > > On Thu, Jul 21, 2016 at 11:59 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 7/21/16, 11:56 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> I’m with you. >>> >>> If the transform stuff has too much overhead, I’d do it as a Bead. We’ll >>> see how it goes… >>> >>> Let’s discuss this some more once we’ve done some of this implementation >>> so there’s something concrete to discuss. >> >> Sounds good. IIRC, some of the current design was motivated by some >> FXG/SVG handling, so keep that in mind as well. I don't have any set >> opinions on how things end up as long as there is bias towards low >> overhead in the JS implementations and it is pay-as-you-go. >> >> Thanks, >> -Alex >> >>
