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 s
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 origin
On 7/21/16, 11:56 AM, "Harbs" 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 t
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.
On Jul 21, 2016, at 9:54 PM, Alex Harui wrote:
>
>
> On 7/21/16, 11:38
On 7/21/16, 11:38 AM, "Harbs" wrote:
>The standard in SVG is declarative. The standard in Canvas is functional
>(very similar to the Flash APIs). Here’s a good write-up comparing Flash
>to Canvas.[1]
Thanks for the link.
IMO, at the lowest level, I would pretty much implement the Canvas API
a
The standard in SVG is declarative. The standard in Canvas is functional (very
similar to the Flash APIs). Here’s a good write-up comparing Flash to Canvas.[1]
I would like to present a unified API so SVG and Canvas could be swapped out
for each other. So for SVG, my idea is to construct the mar
On 7/21/16, 10:19 AM, "Harbs" wrote:
>Unless folks have a problem with it, I’m going to try and refactor some
>naming. If what I do is too drastic, we can revert my changes…
>
>I’ll try and keep my changes in clearly separate commits. I can do it on
>a feature branch if folks prefer.
Well, I'm
Unless folks have a problem with it, I’m going to try and refactor some naming.
If what I do is too drastic, we can revert my changes…
I’ll try and keep my changes in clearly separate commits. I can do it on a
feature branch if folks prefer.
On Jul 21, 2016, at 7:21 PM, Alex Harui wrote:
>
>
Although, I’d probably rename the function to drawPathString() to make it clear
that it’s different than the Flash implementation.
On Jul 21, 2016, at 7:25 PM, Harbs wrote:
> Yes. drawPath is an exception. But curveTo, quadraticCurveTo, etc.should
> behave as it did in Flash.
>
> On Jul 21, 2
Yes. drawPath is an exception. But curveTo, quadraticCurveTo, etc.should behave
as it did in Flash.
On Jul 21, 2016, at 7:21 PM, Alex Harui wrote:
>
>
> On 7/21/16, 7:06 AM, "Harbs" wrote:
>
>> For svg and canvas, the drawing commands map pretty cleanly to their HTML
>> counterparts, so it
On 7/21/16, 7:06 AM, "Harbs" wrote:
>For svg and canvas, the drawing commands map pretty cleanly to their HTML
>counterparts, so it would be pretty clean.
I haven't spent any serious time thinking about it. Just quickly, I saw
flash.display.Graphics.drawPath which seems quite different from S
On 7/21/16, 7:09 AM, "Peter Ent" wrote:
>I agree with Alex in most respects, but have a couple of other
>suggestions, below.
>
>I think the basic package should wrap (thinly, as possible) HTML/JS and
>the SWF implementation mimic that but it doesn't necessarily need to have
>the same names as H
I agree with Alex in most respects, but have a couple of other
suggestions, below.
I think the basic package should wrap (thinly, as possible) HTML/JS and
the SWF implementation mimic that but it doesn't necessarily need to have
the same names as HTML/JS uses and can be more platform agnostic.
I
For svg and canvas, the drawing commands map pretty cleanly to their HTML
counterparts, so it would be pretty clean.
In fact, this is pretty much what GraphicsContainer currently does, but I’m
talking about completing the support and naming it to be more indicative of
what it is.
Basically, If
On 7/21/16, 3:00 AM, "Harbs" wrote:
>3. I’d like an interface which mimics the Flash APIs as closely as
>possible. It might not make sense to have every element have a “graphics”
>object because it could inflate things unnecessarily, but I’m thinking
>that it might make sense to rename Graphic
Harbs-4 wrote
> I have a few issues with the graphics package which I wanted to discuss:
>
> 1. The package name. It’s currently using a generic name, and ultimately,
> I think we’re going to want separate packages for SVG and Canvas. Since
> it’s currently using SVG, I would propose to change the
16 matches
Mail list logo
