eractive. 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
harts, 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 FlexJ
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
cked out the graphics api the first time I've had
exactly this question:
What is it? svg, canvas or whatever...
Olaf
--
View this message in context:
http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Graphics-package-tp54064p54065.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
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 name to
org.apache.f
17 matches
Mail list logo
