Here’s a good article on transforms (and differences with different methods) https://css-tricks.com/transforms-on-svg-elements/
On Jul 12, 2016, at 11:29 AM, Harbs <harbs.li...@gmail.com> wrote: > I did not think about Application. That does put a spanner in the works, but > composition might make sense anyway and proxy everything. It’ll probably be a > lot of work, and there’s probably other things to worry about first. > > HTML needs to be broken down into 3 categories: Normal DOM elements, SVG, and > Canvas. > > Transformations on DOM elements need to be done using CSS, and that should > probably be delegated to a IValuesImpl. It’s supported in IE10 and later and > in IE9 with a prefix.[1] > I think SVG can use CSS as well, but for transforms, they can be specified > directly. > Canvas has a transform method which takes a matrix as well. EaselJS has a > Matrix2D object to simplify matrix transforms. > > Personally, I don’t think I want to use a Spark port for my app because it’s > so heavy. I’m currently doing inventory on exactly which features of Spark > and MX we’re currently using. It will probably make more sense to add support > (as Beads) to regular FlexJS rather than pull in the entire Spark dependency > tree. We’ve been going back and forth between SVG and Canvas, and I think > we’re going to go with a canvas implementation for object manipulation. I’m > probably going to use regular FlexJS components for UI elements. > > That said, it might be interesting to see what happens when I try the Spark > port. > > For Canvas, I’m probably going to expand the CreateJS package to have more > complete coverage and the ability to use EaselJS Stage objects inside a > normal application. I’m also thinking about adding SWF support to the > package. The other way to go about it would be to create a new canvas API set > instead of using EaselJS. That would be a lot more work in the short term. I > don’t know if there would be long-term gains going that route. One thing I > noticed when using EaselJS Matrix2Ds is that the behavior did not seem > identical to the Flash behavior. I don’t know why that was and how easy it > will be to work around the issue. > > As far as architecture goes, I think it would be great if different > implementations could be swapped out with as little pain as possible. If each > rendering path uses the same interfaces, that would be a good thing. > > [1]http://caniuse.com/#feat=transforms2d > On Jul 11, 2016, at 11:16 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 7/11/16, 12:23 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> It could be that instead of subclassing Flash objects, we should be using >>> composition instead… >> >> Maybe. I started out subclassing because it would be lower overhead, and >> so the main class could be the initial class in the SWF. I think the >> initial entry point has to subclass Sprite/MovieClip. >> >> I know that properties like "transform" are exposed by some underlying >> flash class right now, but IMO, FlexJS hasn't "exposed" an API unless >> there is an org.apache.flex.* for it that cross-compiles to JS. >> >> Remember that in FlexJS, there is no one way to do something. We are >> designing the Basic set to thinly wrap what the Browser provides, but with >> a bit of the Flex "flavor". I wish I'd had more time to spend on the >> MX/Spark port because it would probably have exposed a lot of these issues >> as well, but that component set is designed to be much more like regular >> Flex. IMO, we don't want to blindly implement Flash implementations in >> the Basic set. We want to understand how the browser implements various >> features and Flex-ify them by giving the AS and MXML APIs. >> >> So, before "transform" becomes the API for rotating things in the Basic >> set, we want to understand how it is implemented in the browser. Since I >> think you are working with an existing code base from one of your apps, >> you might want to stop and consider whether you want to invest in making >> the MX/Spark port work better. In those component sets we will have a >> "transform" property. >> >> We want FlexJS to be pay-as-you-go, so whatever we do to support rotation >> must be opt-in and not baked into the base APIs for the Basic set like >> IUIBase. It should be possible to build a UI that doesn't need rotation >> and not link in the rotation classes. For the MX/Spark, we are trying to >> implement as many existing Flex APIs as possible, so the support for >> rotation could be baked in. >> >> In the MX/Spark port, I am planning to pull off one compile trick where >> imports of flash.*.* automatically get re-interpreted as flex.*.*. You >> can look at the code in the branch to see that there is a >> flex.display.DisplayObject that doesn't yet support every >> flash.display.DisplayObject API. That's how I think we will incrementally >> implement this port. >> >> In a quick look, it looks like in the browser there is a CSS Transform >> property. And there is 2D and 3D support. So, IMO, in the Basic set, the >> transforms would be specified in CSS and not as properties so the base >> classes don't have to carry around the potential for rotation. It could >> also be a bead of properties that gets plugged in, or even alternate views >> like TextInputViewWithRotation. >> >> At least, that's the way I think about it. We want folks who are coding >> from scratch to have the smallest fastest product. Incremental baking in >> of functionality "just-in-case" is why UIComponent is 13,000 lines long >> and attempts to optimized failed because no one sub-feature was big enough >> to move the needle, but the sum was just too large and unwieldy. >> Pay-as-you-go, opt-in, just-in-time are the mantras I would like to see >> applied to most FlexJS work. In the MX/Spark port, the opposite is true: >> that component set's job is to minimize migration effort at the cost of >> size and performance since the Flex app was already bigger and slower than >> you probably wanted. >> >> Thoughts? >> -Alex >> >>> >>> On Jul 11, 2016, at 10:21 AM, Harbs <harbs.li...@gmail.com> wrote: >>> >>>> Sure they are. >>>> >>>> Try this: >>>> var myRect:org.apache.flex.core.graphics.Rect = new >>>> org.apache.flex.core.graphics.Rect(); >>>> var transform:Matrix = myRect.transform; >>>> >>>> On Jul 11, 2016, at 10:16 AM, Alex Harui <aha...@adobe.com> wrote: >>>> >>>>> >>>>> >>>>> On 7/11/16, 12:06 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>> >>>>>> I believe Bitmaps use Rectangles. >>>>> >>>>> OK but flash.display.Bitmap should not be exposed to the SWC's API >>>>> surface. Bitmap should be wrapped and rectangles in its API should be >>>>> wrapped as well. >>>>> >>>>>> >>>>>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the >>>>>> transform. IF you try to use transformPoint() on that, it’ll return >>>>>> (and >>>>>> expects) a Flash Point. >>>>> >>>>> Again, the transform and flash.geom.Matrix should not be exposed to the >>>>> SWC's API surface. >>>>> >>>>> -Alex >>>>> >>>> >>> >> >
