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 >>>> >>> >> >
