On Thu, Mar 14, 2013 at 12:07 PM, Alex Harui <aha...@adobe.com> wrote:
> > > > On 3/14/13 10:36 AM, "Om" <bigosma...@gmail.com> wrote: > > >> FWIW, the new framework I'm working on is probably going to be less > vector > >> graphic oriented and rely on bitmaps since I think bitmaps are how most > >> things get "skinned" in html/js/css > >> > >> > > This really worries me. Are you saying that we dont want to support FXG > in > > FlexJS? > I eventually want to support everything, but time is of the essence, and I > am going to prioritize stuff that we can get done quickly and that performs > well. I'm not an expert, but I'm told that bitmaps work better in the GPU > than vectors. > It does not have to be an either-or choice. As I said, FXG supports capability of skinning with just bitmaps. Why not work with that as the primary use case. Support for other primitives can be added incrementally. In the end, it is up to the end user developer to use vectors vs. bitmaps for skinning. As Jude mentioned, there are very valid use cases for using vector based skinning. For now, all I want to make sure is that we dont shut down this option by choosing a skinning mechanism that excludes FXG based skinning. > > > > Spark skinning paradigm is one of the best out there. > Aside from the fact there is a consistent way to skin components and you > can > sort of declare a skin in MXML, what else is a must-have for FlexJS? > Not sure if I understand your question, but here goes: I care about the workflow most importantly. In my mind, the idea workflow would be this: 1. Designers create visual designs of the app in tools they are comfortable with (Fireworks, Photoshop, etc.) 2. We export it to simpler assets (FXG or SVG + pngs, etc.) 3. We bring all the assets into the Flex project and skin the app 4. Users can chose Compile to SWF or Compile to HTML And the end results should be as close to each other in terms of the skinning of the app (in this scenario, I am less concerned about the business logic, etc.) > > > Are we willing to > > throw it out because HTML/JS cant support it? That is not a vision of > Flex > > that existing developers would like (including me) > > > > At the very minimum, we should support the BitmapImage (and related > > classes) That would be better than no FXG support at all. > If you want to take it on, go ahead, but I'm not sure how many Adobe tools > will output FXG going forward. Are you willing to run an older version to > keep FXG around? Especially if it doesn't perform well? > Older version of the tool, or older version of Flex? I dont mind if I have to use the older version of the tool just so that I have support for FXG. In terms keeping older (i.e. current) version of Flex for skinning, I think as a developer I would choose the newer, better performing version of Flex. But when working with a large team with UX designers, UI designers, I want the ability Flex 4 skinning paradigm. In other words, to get buy in from large teams with established workflows, lack of FXG skinning would be a deal breaker. I have worked with workflows before Flex 4 and they have consistently been a nightmare. Most designers are not familiar with Flash Pro. And managing assets as swf files is not fun for a developer as well. > > If we're working with bitmap skins, sure there will be scaling issues, but > you will be able to use the same Adobe tools to generate these bitmaps. > > > > As an aside, most FXG elements have SVG equivalents. In that sense FXG > is > > only an XSLT transformation away from SVG (I had to do the reverse > > transformation for a project a while ago) > > > > Most modern browsers support inlining SVG with HTML5 [1] If we can skin > > HTML elements using SVG like this [2], that would be a big win for us. > > This would bring us so much closer to how we skin MXML with FXG. > > > > FYI, there is a whole bunch of inline SVG + HTML5 usage examples here [3] > > > If that's what you want to work on, go for it. It just isn't high on my > personal priority list. > I would definitely give this a go. But I have too many Apache Flex related things on my plate right now. I am hoping others who are reading this can pick up this idea and run with it. But, I will get into this when I get some time, for sure. I am piping up now so that we dont lose ability to work with FXG in FlexJS. Thanks, Om
