Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

Probably time to re-open this debate...

As I understand it, there are 3 issues:

1.  When migrating code, it is important to where your code is relying on
Flash APIs that aren't supported by FlexJS, but if UIBase extends Sprite
the compiler will happily let your code make calls to Sprite APIs.

2.  In code completion in Flash Builder and maybe other IDEs, lots of
non-FlexJS APIs are offered.

3.  When migrating code, an override of a SWF-only API will result in a
compile error when compiling for JS since that API has no base class
implementation on the JS side.  And vice versa.

Wrapping Sprite solves all of these problems, but introduces new ones like
the need for a new event subsystem, and adds runtime and download overhead
to every SWF.  I would rather solve these problems in the compiler so
there is no runtime overhead.

Here are my latest thoughts:

A) We could require the exact same API surfaces on both SWF and JS but
that seems like excessive overhead.  Would it be so bad if your code might
run into a compile error during the JS compile if the SWF compile comes
out clean?  I think that's a reasonable price to pay so everyone doesn't
have to pay download and runtime overhead.
B) I don't use Flash Builder code completion myself since I pretty much
know the APIs.  When folks use it, do they want all public APIs or would
they really want the list to be filtered to "usable" APIs.  For example,
in Flex UIComponent, there are public APIs like the "initialized" property
that application developers should not be setting.  I'm wondering if we
should create different SWCs that have different APIs filtered on ASDoc
directives so the "application" version of the SWC doesn't show APIs you
shouldn't be using in building your app.  Of course, when you finally
output something to run, you may still get errors if you used APIs we hid
from you.  Having filters in ASDoc would also help ASDoc filter away APIs
most folks won't need.

Thoughts?

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/26/16, 1:01 PM, "Harbs" <ha...@gmail.com> wrote:

>Maybe we can have a compiler option to rename properties that are not
>wrapped in platform-specific code?

Possibly.  We'll see how often such an issue comes up as the tool chain
evolves.

A key point to keep in mind from this thread is that Flex does have a tool
chain, which means we can not only catch a ton of errors before the code
is submitted to the browser, but we can also alter the code the developer
has written.  Not all JS development workflows have a tool chain, so we
should use it to our advantage.

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

Maybe we can have a compiler option to rename properties that are not wrapped in platform-specific code?

On Oct 26, 2016, at 8:43 PM, Alex Harui <ah...@adobe.com> wrote:

> For sure,
> if you unwittingly try to add a buttonMode property to a UIBase subclass
> you'll find out that the underlying Sprite already has such a property.

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

There’s also an issue that Flash uses ARGB, while the default in browsers seems to be RGBA.

I think simply avoiding uint representations of RGBA is the simplest solution…

On Oct 27, 2016, at 9:43 AM, Alex Harui <ah...@adobe.com> wrote:

>> This code works in Flash because it supports argb. I took the easy way
>> out by simply rejecting argb values, but I guess we could break off the
>> alpha channel and set the alpha with that value.
> 
> That sound like there are multiple possible solutions so there should be
> multiple classes, one for each solution.  IIRC, CSS has RGB and RGBA types
> and we may need to support both properly.
> 
> Maybe we need to find a way to introduce an RGB and RGBA type in an
> efficient way so you can strongly type your color handling code. IMO it is
> a bit of a hack to be using uint for a Color, but that's how Flash does it.

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/26/16, 11:51 PM, "Harbs" <ha...@gmail.com> wrote:

>I don’t need it now that we changed our code. I added the check because I
>thought other might be bitten by the same issue.
>
>If we remove the check, I’m not going to add another class.

I do envision "debug-mode" beads and classes that do parameter/value
validation, since that will speed up development, but I hope to find a way
to easily swap those out for production beads that don't do
parameter/value validation.

It's ok to leave the checks in for now, but hopefully some day there will
be a way to opt-in/out such code.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

I don’t need it now that we changed our code. I added the check because I thought other might be bitten by the same issue.

If we remove the check, I’m not going to add another class.

On Oct 27, 2016, at 9:43 AM, Alex Harui <ah...@adobe.com> wrote:

> 
> Every bit of code costs in CPU and download size.  It all adds up
> gradually.  And I'd bet there are a significant number of applications
> that don't need these checks in production.  You are welcome to create
> ValidatingSolidColor if you really need it.

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/26/16, 10:41 PM, "Harbs" <ha...@gmail.com> wrote:

>Sure, components should try and validate their values, but client code is
>not necessarily components, and it’s pretty easy to introduce a bug where
>client code supplies a wrong value.

IMO, if you are using typed ValueObjects you should do some validation
when storing any value, not just colors, in the ValueObjects.

>
>I do a lot of loading of content programmatically. This includes things
>like colors. The dynamic content does not cleanly fit into MXML and pure
>components. Setting properties using client code is the norm.
>
>Are worried about the performance implications of an extra check?

Every bit of code costs in CPU and download size.  It all adds up
gradually.  And I'd bet there are a significant number of applications
that don't need these checks in production.  You are welcome to create
ValidatingSolidColor if you really need it.

>
>In our case we had some code like this in our app:
>
>			var fill:SolidColor = new SolidColor(0xFFFF0000, 1);
>			var stroke:SolidColorStroke = new SolidColorStroke(0xFFFFFFFF,1, 1);
>
>The color value could just as easily have been a variable whose value is
>determined at runtime.
>
>This code works in Flash because it supports argb. I took the easy way
>out by simply rejecting argb values, but I guess we could break off the
>alpha channel and set the alpha with that value.

That sound like there are multiple possible solutions so there should be
multiple classes, one for each solution.  IIRC, CSS has RGB and RGBA types
and we may need to support both properly.

Maybe we need to find a way to introduce an RGB and RGBA type in an
efficient way so you can strongly type your color handling code. IMO it is
a bit of a hack to be using uint for a Color, but that's how Flash does it.

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

Sure, components should try and validate their values, but client code is not necessarily components, and it’s pretty easy to introduce a bug where client code supplies a wrong value.

I do a lot of loading of content programmatically. This includes things like colors. The dynamic content does not cleanly fit into MXML and pure components. Setting properties using client code is the norm.

Are worried about the performance implications of an extra check?

In our case we had some code like this in our app:

			var fill:SolidColor = new SolidColor(0xFFFF0000, 1);
			var stroke:SolidColorStroke = new SolidColorStroke(0xFFFFFFFF,1, 1);

The color value could just as easily have been a variable whose value is determined at runtime.

This code works in Flash because it supports argb. I took the easy way out by simply rejecting argb values, but I guess we could break off the alpha channel and set the alpha with that value.

On Oct 26, 2016, at 11:46 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/26/16, 12:59 PM, "Harbs" <ha...@gmail.com> wrote:
> 
>> Pretty likely. The color values can come from anywhere. We happened to
>> have the values coming from compiled code (so compile-time checks could
>> have caught that case), but other colors in our app are created at
>> runtime.
>> 
>> Runtime colors seems like a likely scenario.
> 
> Maybe I'm not understanding, but I would that the recommended practice is
> that a user-determined color is validated at the point of user
> interaction.  IOW, a ColorPicker will only return valid colors.  Even a
> TextInput where you type in something and want a valid color out of it
> should validate the color at that point, before it goes into ValueObjects
> and into instances of SolidColor/SolidColorStroke.
> 
> Thoughts?
> -Alex
> 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/26/16, 12:59 PM, "Harbs" <ha...@gmail.com> wrote:

>Pretty likely. The color values can come from anywhere. We happened to
>have the values coming from compiled code (so compile-time checks could
>have caught that case), but other colors in our app are created at
>runtime.
>
>Runtime colors seems like a likely scenario.

Maybe I'm not understanding, but I would that the recommended practice is
that a user-determined color is validated at the point of user
interaction.  IOW, a ColorPicker will only return valid colors.  Even a
TextInput where you type in something and want a valid color out of it
should validate the color at that point, before it goes into ValueObjects
and into instances of SolidColor/SolidColorStroke.

Thoughts?
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

Pretty likely. The color values can come from anywhere. We happened to have the values coming from compiled code (so compile-time checks could have caught that case), but other colors in our app are created at runtime.

Runtime colors seems like a likely scenario.

On Oct 26, 2016, at 8:43 PM, Alex Harui <ah...@adobe.com> wrote:

> I saw a commit today that added range checks to color values passed in to
> SolidColor and SolidColorStroke.  What are the odds you will need those
> checks in production? 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/25/16, 12:40 PM, "Harbs" <ha...@gmail.com> wrote:

>
>My opinion comes from a lot of frustration related to the subclassing. If
>you can fix all that and prove me wrong, I’m a happy camper… ;-)

I want to set expectations properly.  There might be some usability
trade-offs or rough edges around working with the unwrapped set. For sure,
if you unwittingly try to add a buttonMode property to a UIBase subclass
you'll find out that the underlying Sprite already has such a property.
My main goal is to try to use the tool chain to give motivated people the
opportunity to shave off every line of code they don't need in production.
 We just saw that there is are upper limits on the size of an IOS app.  We
don't want to unnecessarily contribute to exceeding that limit.  A
framework developer has to consider usability, but needs to reserve CPU
cycles and download bytes for the application developer.  I want to handle
usability in the tool chain.

I saw a commit today that added range checks to color values passed in to
SolidColor and SolidColorStroke.  What are the odds you will need those
checks in production?  Some day, I hope our tool chain will let you easily
swap in DebugSolidColor and DebugSolidColorStroke classes that have those
checks and switch to SolidColor and SolidColorStroke without those checks
in production.

I should be starting on copying the Basic components elsewhere today.

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

I forgot to respond to this earlier. Some inline responses:

> What is the logic behind that statement?  The wrapping object is an
> EventDispatcher.  Each EventDispatcher eats up some 40 bytes.

I forgot about EventDispatcher. I was thinking it’s a simple object. You’re right. There is a memory hit.

> Where did you get the 0.02ms number?

Benchmarks I saw. I did not do testing myself, but getter access seems to be really fast.

> The current SWF-side event model subclasses flash.events.Event.  I don't
> think there is any wrapping going on.

Wrapping was the wrong word. I meant subclassing.

> I will need to understand you are referring to.  Since there is no
> wrapping going on, I'm not sure what you are describing.

We had all kinds of typing issues related to events. When you have your toolchain, I’ll work on creating an itemized list of issues and we’ll see if you can fix them all… ;-)

> Yep, I think that's the best plan.

Great. Let’s go for it.

> I would like to
> change the URI for the wrapped set to something else: migration, full,
> flex, other ideas?

Anything is fine with me. js even? This might all be temporary, so the exact name of the URI does not concern me very much.

> I am going to close this post with a long story.

I’m sorry for being so difficult. If you can solve the problems — that’s fine with me. FWIW, I consider your vast experience the greatest asset the Flex project has and I value your opinion greatly. My opinion comes from a lot of frustration related to the subclassing. If you can fix all that and prove me wrong, I’m a happy camper… ;-)

Thanks,
Harbs

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/23/16, 5:17 AM, "Harbs" <ha...@gmail.com> wrote:

>
>On Oct 21, 2016, at 10:12 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> 
>> 
>> Carlos is working on an MDL set.  We want to make sure FlexJS can handle
>> more than one set.  We don't have to all work on one set.
>
>There’s a difference between specific components based off the basic
>architecture, and an entire alternate set for everything based off of
>UIHTMLElementWrapper. If you want to use MDL components, it makes sense
>to use an mdl prefix. FWIW, I would have thought that MDL would have been
>a set of beads, but I guess a set of components is probably easier to use.

Internally, some of the createElement calls for MDL will have to build a
different DOM tree than what the basic set does.

>
>>> 
>>> AFAIK, the only performance overhead in wrapping Flash components is an
>>> extra getter/setter call. I don’t see how there would be any extra
>>>memory
>>> overhead. 
>> 
>> Instead of creating a new Sprite, you are creating a new Sprite and
>> another object to wrap it.  This is worrisome in the sense that, for
>>every
>> person who is struggling to get a certain update rate in their app,
>> wrapping essentially means there are twice as many objects to be updated
>> in the same amount of time, although the update time of the wrapper may
>> not be the same as the update time of the inner widget.  Twice as many
>> objects is twice as much work for the Garbage Collector.  It is more
>>lines
>> to step through when debugging.  If we told potential FlexJS customers
>>to
>> wrap all of their code in another layer in order to use FlexJS I think
>>we
>> would have fewer customers.
>
>I have no idea what you mean by twice the updates. Why does extra objects
>effect that?
>
>It’s twice the number of objects, but the size of both objects together
>is not bigger than one.

What is the logic behind that statement?  The wrapping object is an
EventDispatcher.  Each EventDispatcher eats up some 40 bytes.

>We’re all used to having extra getter calls when debugging, so I’m not
>concerned about that issue. I don’t know how the garbage collector works.
>Is the work based on the number of objects, or the size of the objects?

Number of objects.

>It does not solve the problem that lots of things are happening under the
>hood related to the fact that the objects are masquerading as something
>other that what they are.

I don't see it as masquerading.  The platform implementations just share a
common API.

>
>If there will be performance issues for mobile or otherwise, I don’t
>believe it’s going to be the wrapping that causes the problem.
>
>> Now from my experience with Flex, I saw some things happen.  Flex's job
>> was to put a layer over Flash and essentially hide all the Flash-isms,
>> especially frames, and make an API that was more "programmer-oriented".
>> You were supposed to use SystemManager instead of Stage, for example.
>>But
>> when I peek at other people's apps, I see a lot of use of Flash APIs
>> anyway.  Why?  Because they needed to get down to the lower-level for
>> optimization.  And then, folks started creating other lightweight
>> frameworks as alternatives to Flex.  I also saw the argument that my
>> change only causes 10ms delay.  I after seeing it 100 times, we had a
>>full
>> second delay and nobody could point to what to remove to try to get it
>> back to something ignorable.
>
>We’re not talking about a 10ms delay. We’re talking about a 0.02 ms
>delay. That’s not going o be the performance bottleneck.

Where did you get the 0.02ms number?

>
>> Also note: the reason MouseEvent doesn't extend Event doesn't have
>> anything to do with wrapping Sprite or not.  And any inconsistencies
>> between the JS and SWF event model simply need to be resolved.  I think
>> resolving it so the unwrapped set matches the JS side will lots easier
>> than writing a whole new event model for wrapped Sprites.
>
>Yes it does. Flash objects dispatch Flash events and we’re wrapping Flash
>Events and MouseEvents.

The current SWF-side event model subclasses flash.events.Event.  I don't
think there is any wrapping going on.

>The fact that we’re handling Flash MouseEvents creates an entire class of
>issues which would not exist if we did not use the Flash UI event system
>for mouse events. Unless we do some hack to clobber every Flash event
>before it propagates, we’re going to be chasing down lots of edge case
>issues related to casting bugs and odd side effects of event bubbling.
>(as we already saw) Wrapping the Flash objects solves this problem in the
>cleanest possible way because unless you do so specifically, event
>listeners are not attached to the underlying Flash objects.

I will need to understand you are referring to.  Since there is no
wrapping going on, I'm not sure what you are describing.

>
>
>It might be that the only way to resolve this is to create that tool
>chain and have me try to break it. ;-)

Yep, I think that's the best plan.

>
>If that means I can continue working with the wrapped components for the
>time being and changes are applied to that, I’m fine with this. If you
>can get your tool chain working, I’ll be happy to spend the time trying
>to port my code to use that and see what breaks. Then we can have a
>better idea how well it really works…

I will move the unwrapped set to a different SWC (or set of SWCs) some
time this week.  Then we can try to merge your branch.  I would like to
change the URI for the wrapped set to something else: migration, full,
flex, other ideas?

I am going to close this post with a long story.  I am a believer that
history repeats itself.  The arguments you are presenting here are the
same ones I heard many times over the years.  Over 10 years of Flex at
Adobe, 1000's of changes were made.  Nearly every one of those added just
a little bit of code and thus slowed the framework just a little bit.
Early on, I prototyped a smaller framework like what you see in the basic
set.  But the emphasis was on how quickly you could put together a POC.
Flex grew in popularity, but we started receiving more and more problems
with folks trying to meet some performance criteria at the end of their
schedule.  At one point, I visited a major consumer software company where
they complained that they could not get the first-time startup time to an
acceptable point.  We had no answer for them, because we had baked in
1000's of small changes and couldn't back any of them out without breaking
backward-compatibility.  There were no low-hanging fruit that would make a
measurable difference.  As a result, I don't think Flex was ever used to
create an app that "everybody" uses.  Lots of ActionScript apps are in the
app stores, but I'm not sure how much Flex is used in them.

So from that experience, I became a code-minimalist.  For 4.5 years I've
been preaching that FlexJS is about pay-as-you-go, just-in-time instead of
just-in-case.  Fortunately, because FlexJS can support multiple component
sets, folks can create component sets with different philosophies, but I
am certain I want to have one that is truly bare bones.  When you need a
bit more performance, you might trade-off some usability to get there.
Folks at least should have a choice. I don't expect the basic set to be
the most popular set.  It just has to be there when you need it.
Otherwise, you will go away and not come back.

Also, I am a resource-minimalist.  While it is amazing to see how fast
networks and CPUs are these days, the fact is, everybody is competing for
those resources.  The app developer using the framework is often going to
totally push the boundaries of how much other stuff can be done in some
amount of time.  The framework should not waste cycles that app developer
might need.  It is tempting to think there is plenty of resources, but I
would like Flex to be the choice for folks who run apps in constrained
environments, whether that is Cordova on a mobile phone, or a conventional
computer running a virus scan or backup, or trying to get data over a
network while some other task is playing a video.

So that's why I fight for every function call.  I watched Flex grow too
fat once already.  The plan for FlexJS has always included a "heavier" set
with lots of stuff baked in to make rapid prototyping rapid, but the basic
set really needs to be basic.  The more places FlexJS can work, the better
off we all will be.

Thanks for reading,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

On Oct 21, 2016, at 10:12 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> Carlos is working on an MDL set.  We want to make sure FlexJS can handle
> more than one set.  We don't have to all work on one set.

There’s a difference between specific components based off the basic architecture, and an entire alternate set for everything based off of UIHTMLElementWrapper. If you want to use MDL components, it makes sense to use an mdl prefix. FWIW, I would have thought that MDL would have been a set of beads, but I guess a set of components is probably easier to use.

>> 
>> AFAIK, the only performance overhead in wrapping Flash components is an
>> extra getter/setter call. I don’t see how there would be any extra memory
>> overhead. 
> 
> Instead of creating a new Sprite, you are creating a new Sprite and
> another object to wrap it.  This is worrisome in the sense that, for every
> person who is struggling to get a certain update rate in their app,
> wrapping essentially means there are twice as many objects to be updated
> in the same amount of time, although the update time of the wrapper may
> not be the same as the update time of the inner widget.  Twice as many
> objects is twice as much work for the Garbage Collector.  It is more lines
> to step through when debugging.  If we told potential FlexJS customers to
> wrap all of their code in another layer in order to use FlexJS I think we
> would have fewer customers.

I have no idea what you mean by twice the updates. Why does extra objects effect that?

It’s twice the number of objects, but the size of both objects together is not bigger than one. We’re all used to having extra getter calls when debugging, so I’m not concerned about that issue. I don’t know how the garbage collector works. Is the work based on the number of objects, or the size of the objects?

>> 
>> Now, back to the problem of not wrapping Sprite:
>> 
>> Yes. The case I mentioned is a much bigger problem in migrated code than
>> new code (and in new code there’s still the issue of undocumented
>> reserved properties when targeting Flash), but it’s not the only issue.
>> It’s been a while, and I don’t remember all the nuances of the issues we
>> encountered. Maybe Yishay remembers more.
>> 
>> We encountered numerous issues related to events. Some of the problems
>> were related to the fact that event bubbling is different in Flash than
>> it is in JS. Some of the problems were due to the fact that the events
>> were dispatched by the Flash objects — those issues were at least
>> partially due to the fact that Flex MouseEvent does not subclass the Flex
>> Event. I don’t see any way of fixing that other than wrapping Sprite. I
>> think we need to make events identical across platforms.
>> 
>> There are possibly issues I’m not remembering now, and there’s possibly
>> other issues we did not run into.
>> 
>> Again: My objection is that I believe the idea of having
>> platform-specific implementation details leaking through is fundamentally
>> wrong and should be avoided if at all possible.
> 
> I guess I don't understand why it is wrong.  IMO, you were the first
> pioneer and I'm really thankful that you took the risk to do so.  In US
> history, the pioneers had a covered wagon pulled by an ox.  There were no
> paved roads.  Some days, they were only able to go one mile!.  You found
> that by taking an extra mattress and sitting on it, it made the ride more
> bearable.  However, the tool chain is slowly coming behind you paving
> those roads.  I think I will be able to fill in every bump in the road you
> went over.  If there is something I can't fill in, I would like to
> identify what that is, because that would definitely make me change my
> opinion.  IMO, folks just aren't going to need an extra mattress.  You can
> argue that the ox is so strong that it doesn't matter, but if you do try
> to drive off-road and get stuck in the mud or there are other things you
> would much rather pack into your wagon, you will want to leave that
> mattress behind.  Just this week there is a thread about mobile
> performance.

Again. We already agreed that there’s no way to cover the bumps for migrated code. Also, if someone tries to add scaleX/scaleY or a  transform method, they will get an error despite the fact that these methods and properties are not documented. All the tool chain can do is warn about the issue. It does not solve the problem that lots of things are happening under the hood related to the fact that the objects are masquerading as something other that what they are.

If there will be performance issues for mobile or otherwise, I don’t believe it’s going to be the wrapping that causes the problem.

> Now from my experience with Flex, I saw some things happen.  Flex's job
> was to put a layer over Flash and essentially hide all the Flash-isms,
> especially frames, and make an API that was more "programmer-oriented".
> You were supposed to use SystemManager instead of Stage, for example.  But
> when I peek at other people's apps, I see a lot of use of Flash APIs
> anyway.  Why?  Because they needed to get down to the lower-level for
> optimization.  And then, folks started creating other lightweight
> frameworks as alternatives to Flex.  I also saw the argument that my
> change only causes 10ms delay.  I after seeing it 100 times, we had a full
> second delay and nobody could point to what to remove to try to get it
> back to something ignorable.

We’re not talking about a 10ms delay. We’re talking about a 0.02 ms delay. That’s not going o be the performance bottleneck.

Also, lots of times it was because using the Flash APIs was simpler. I for one did not know you were “supposed” to use SystemManager instead of Stage. When I needed to do something, I looked through the docs to find something helpful and used the first thing I found. Since Stage was the top level parent, using those properties make sense.

Leaving a back-door open for optimization is fine, but I think the front door should have a clean entrance.

> Also note: the reason MouseEvent doesn't extend Event doesn't have
> anything to do with wrapping Sprite or not.  And any inconsistencies
> between the JS and SWF event model simply need to be resolved.  I think
> resolving it so the unwrapped set matches the JS side will lots easier
> than writing a whole new event model for wrapped Sprites.

Yes it does. Flash objects dispatch Flash events and we’re wrapping Flash Events and MouseEvents. The fact that we’re handling Flash MouseEvents creates an entire class of issues which would not exist if we did not use the Flash UI event system for mouse events. Unless we do some hack to clobber every Flash event before it propagates, we’re going to be chasing down lots of edge case issues related to casting bugs and odd side effects of event bubbling. (as we already saw) Wrapping the Flash objects solves this problem in the cleanest possible way because unless you do so specifically, event listeners are not attached to the underlying Flash objects.

>> 
>> We have a conflict between ideals here. You want a the highest possible
>> performance under all circumstances, and I want the highest level of
>> compatibility across platforms under all circumstances.
> 
> I think the tool chain can get you that compatibility so there is no
> conflict.  I'm still wondering what the killer scenario is that the tool
> chain cannot solve.  I am open to the idea that there is one.

Again, I think it’s not just a toolchain problem. It’s an inconsistency between documentation and code and a framework which is inherently more fragile. (Event issues that we had is one example of the fragility.)

It might be that the only way to resolve this is to create that tool chain and have me try to break it. ;-)

>> These two ideals are at head with each other here, and we’re going to
>> have to decide which one is more important. I think I’ve made opinion
>> clear on that question. The performance issue is a theoretical one which
>> I don’t believe will have practical implications, while the compatibility
>> one is a practical one which already bit me. Trying to maintain two
>> complete component sets at this point I believe to be counterproductive
>> and I don’t believe it will resolve performance issues that might arise
>> anyway. If we identify use cases where performance is an issue, I would
>> suggest specific components designed for those use cases (and not a whole
>> new set).
> 
> I would like to work on one Basic set too, but your set doesn't sound like
> it is Basic.  It sounds like it is aggregating APIs into the component
> surface to simplify migration.  And that's fine with me.  I would love to
> have a component set tuned towards migration.  I just would caution about
> using your experience with a new tool chain to make decisions that we will
> carry around for a long time.
> 
> Maybe the answer is that I copy the current unwrapped Basic set to new
> SWCs, then you can drop the wrapped set on top.  Then I will work on the
> tool chain to see if we can resolve all of your issues without wrapping.

If that means I can continue working with the wrapped components for the time being and changes are applied to that, I’m fine with this. If you can get your tool chain working, I’ll be happy to spend the time trying to port my code to use that and see what breaks. Then we can have a better idea how well it really works…

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/21/16, 3:26 AM, "Harbs" <ha...@gmail.com> wrote:

>Let’s see if I can do a better job at explaining myself.
>
>> Seems like that would just stomp on the current basic set.
>
>Yes. And I think that’s appropriate for now.
>
>When I say default, I mean that we should have one set of components that
>we’re all working on for now. We all have limited time, and splitting our
>time over two component sets is going to add significant overhead.
>Migrating the port to a new component set seem like a big job and will
>take time I do not have. Also, telling new users which component set to
>use is going to add extra friction to adapting the framework.

Carlos is working on an MDL set.  We want to make sure FlexJS can handle
more than one set.  We don't have to all work on one set.

>
>AFAIK, the only performance overhead in wrapping Flash components is an
>extra getter/setter call. I don’t see how there would be any extra memory
>overhead. 

Instead of creating a new Sprite, you are creating a new Sprite and
another object to wrap it.  This is worrisome in the sense that, for every
person who is struggling to get a certain update rate in their app,
wrapping essentially means there are twice as many objects to be updated
in the same amount of time, although the update time of the wrapper may
not be the same as the update time of the inner widget.  Twice as many
objects is twice as much work for the Garbage Collector.  It is more lines
to step through when debugging.  If we told potential FlexJS customers to
wrap all of their code in another layer in order to use FlexJS I think we
would have fewer customers.

>
>Now, back to the problem of not wrapping Sprite:
>
>Yes. The case I mentioned is a much bigger problem in migrated code than
>new code (and in new code there’s still the issue of undocumented
>reserved properties when targeting Flash), but it’s not the only issue.
>It’s been a while, and I don’t remember all the nuances of the issues we
>encountered. Maybe Yishay remembers more.
>
>We encountered numerous issues related to events. Some of the problems
>were related to the fact that event bubbling is different in Flash than
>it is in JS. Some of the problems were due to the fact that the events
>were dispatched by the Flash objects — those issues were at least
>partially due to the fact that Flex MouseEvent does not subclass the Flex
>Event. I don’t see any way of fixing that other than wrapping Sprite. I
>think we need to make events identical across platforms.
>
>There are possibly issues I’m not remembering now, and there’s possibly
>other issues we did not run into.
>
>Again: My objection is that I believe the idea of having
>platform-specific implementation details leaking through is fundamentally
>wrong and should be avoided if at all possible.

I guess I don't understand why it is wrong.  IMO, you were the first
pioneer and I'm really thankful that you took the risk to do so.  In US
history, the pioneers had a covered wagon pulled by an ox.  There were no
paved roads.  Some days, they were only able to go one mile!.  You found
that by taking an extra mattress and sitting on it, it made the ride more
bearable.  However, the tool chain is slowly coming behind you paving
those roads.  I think I will be able to fill in every bump in the road you
went over.  If there is something I can't fill in, I would like to
identify what that is, because that would definitely make me change my
opinion.  IMO, folks just aren't going to need an extra mattress.  You can
argue that the ox is so strong that it doesn't matter, but if you do try
to drive off-road and get stuck in the mud or there are other things you
would much rather pack into your wagon, you will want to leave that
mattress behind.  Just this week there is a thread about mobile
performance.

Now from my experience with Flex, I saw some things happen.  Flex's job
was to put a layer over Flash and essentially hide all the Flash-isms,
especially frames, and make an API that was more "programmer-oriented".
You were supposed to use SystemManager instead of Stage, for example.  But
when I peek at other people's apps, I see a lot of use of Flash APIs
anyway.  Why?  Because they needed to get down to the lower-level for
optimization.  And then, folks started creating other lightweight
frameworks as alternatives to Flex.  I also saw the argument that my
change only causes 10ms delay.  I after seeing it 100 times, we had a full
second delay and nobody could point to what to remove to try to get it
back to something ignorable.

Also note: the reason MouseEvent doesn't extend Event doesn't have
anything to do with wrapping Sprite or not.  And any inconsistencies
between the JS and SWF event model simply need to be resolved.  I think
resolving it so the unwrapped set matches the JS side will lots easier
than writing a whole new event model for wrapped Sprites.

>
>We have a conflict between ideals here. You want a the highest possible
>performance under all circumstances, and I want the highest level of
>compatibility across platforms under all circumstances.

I think the tool chain can get you that compatibility so there is no
conflict.  I'm still wondering what the killer scenario is that the tool
chain cannot solve.  I am open to the idea that there is one.

>These two ideals are at head with each other here, and we’re going to
>have to decide which one is more important. I think I’ve made opinion
>clear on that question. The performance issue is a theoretical one which
>I don’t believe will have practical implications, while the compatibility
>one is a practical one which already bit me. Trying to maintain two
>complete component sets at this point I believe to be counterproductive
>and I don’t believe it will resolve performance issues that might arise
>anyway. If we identify use cases where performance is an issue, I would
>suggest specific components designed for those use cases (and not a whole
>new set).

I would like to work on one Basic set too, but your set doesn't sound like
it is Basic.  It sounds like it is aggregating APIs into the component
surface to simplify migration.  And that's fine with me.  I would love to
have a component set tuned towards migration.  I just would caution about
using your experience with a new tool chain to make decisions that we will
carry around for a long time.

Maybe the answer is that I copy the current unwrapped Basic set to new
SWCs, then you can drop the wrapped set on top.  Then I will work on the
tool chain to see if we can resolve all of your issues without wrapping.

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

Let’s see if I can do a better job at explaining myself.

> Seems like that would just stomp on the current basic set.

Yes. And I think that’s appropriate for now.

When I say default, I mean that we should have one set of components that we’re all working on for now. We all have limited time, and splitting our time over two component sets is going to add significant overhead. Migrating the port to a new component set seem like a big job and will take time I do not have. Also, telling new users which component set to use is going to add extra friction to adapting the framework.

AFAIK, the only performance overhead in wrapping Flash components is an extra getter/setter call. I don’t see how there would be any extra memory overhead. To convince me that the performance issue is a problem, we’re going to need a real-life example where getters and setters make a MEASURABLE difference in performance. Every benchmark I’ve seen indicates that to have any measurable impact by using getters and setters you need MANY millions of accesses. At even ten million accesses we’re talking at most 1/5 of a second. (probably less depending on the type of getter access) I find it hard to believe that we’re going to come up with a real life case where that will make a difference and there’s not a pile of other code causing much bigger performance issues. In fact, even the non-refactored code is already overriding the setters for most properties, so the issue is really only with the getters.

If we come up with that use case (i.e. ridiculously large data grids or particle animations), I think there will be other refactoring we’re going to need to do to improve performance anyway. (i.e. image caches for item renderers and GPU optimizations)

Now, back to the problem of not wrapping Sprite:

Yes. The case I mentioned is a much bigger problem in migrated code than new code (and in new code there’s still the issue of undocumented reserved properties when targeting Flash), but it’s not the only issue. It’s been a while, and I don’t remember all the nuances of the issues we encountered. Maybe Yishay remembers more.

We encountered numerous issues related to events. Some of the problems were related to the fact that event bubbling is different in Flash than it is in JS. Some of the problems were due to the fact that the events were dispatched by the Flash objects — those issues were at least partially due to the fact that Flex MouseEvent does not subclass the Flex Event. I don’t see any way of fixing that other than wrapping Sprite. I think we need to make events identical across platforms.

There are possibly issues I’m not remembering now, and there’s possibly other issues we did not run into.

Again: My objection is that I believe the idea of having platform-specific implementation details leaking through is fundamentally wrong and should be avoided if at all possible.

Another point:

I believe FlexJS will primarily be adopted by two groups of developers:

1. Developers migrating from Flash and classic Flex.
2. JS developers who could not care less about Flash support.

For the first group wrapping Sprite is really important as I’ve already explained. For the second group Flash performance is a non-issue. I’m not sure which developer we’re worrying about vis a vis getter performance.

We have a conflict between ideals here. You want a the highest possible performance under all circumstances, and I want the highest level of compatibility across platforms under all circumstances. These two ideals are at head with each other here, and we’re going to have to decide which one is more important. I think I’ve made opinion clear on that question. The performance issue is a theoretical one which I don’t believe will have practical implications, while the compatibility one is a practical one which already bit me. Trying to maintain two complete component sets at this point I believe to be counterproductive and I don’t believe it will resolve performance issues that might arise anyway. If we identify use cases where performance is an issue, I would suggest specific components designed for those use cases (and not a whole new set).

Thanks,
Harbs

On Oct 21, 2016, at 8:06 AM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/20/16, 9:49 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> I feel like we’re not communicating. No. I want to merge as-is.
> 
> I don't understand how that would create a second component set.  Seems
> like that would just stomp on the current basic set.
> 
>> 
>> I think that wrapping should be the default for all components. I feel
>> that having Flash properties leaking though is worse than a bit of
>> redirection for 99% of use cases. I can’t stress how much of an issue
>> that the Flash properties and methods leaking through was for us.
>> Spark-like components was not the issue. Platform-specific implementation
>> details leaking through is the issue and it’s more of an issue than
>> possible performance problems IMO.
>> 
>> We have not demonstrated that the performance impact will even be an
>> issue. If that’s demonstrated, we can make leaky high-preformance
>> alternates for those cases.
> 
> I'll work on getting profiler information, but I have a feeling it won't
> convince you.  I have proposed tool chain solutions to I think every
> problem you have described.  If not, it is probably time to write down
> explicit examples so everybody can understand the issue.  I must clearly
> be missing something.  We have examples that work without wrapping on the
> SWF-side.  The API conflicts you hit were from migrating existing Flex
> code and I don't think folks starting new projects will run into the same
> problems and if they want to deploy a SWF version, may be more interested
> in seeing that the output has as little overhead as possible.
> 
> The URI for the basic set is currently
> "library://ns.apache.org/flexjs/basic".  I don't quite get how a wrapping
> pattern on the SWF-side counts as "basic".  I would offer that the
> component set with wrapping have the URI
> "library://ns.apache.org/flexjs/migration".  Feel free to propose an
> alternate set of URIs if you are convinced your wrapping set is "basic".
> I don't care that much about the names as long as the meaning is clear.
> If you want the HTML.swc to contain the wrapped set, propose SWC names for
> the unwrapped set.  Could be Basic.swc or BasicHTML.swc.
> 
> I have no idea what the "default" set of components will be for FlexJS.  I
> doubt it will be what is currently "basic".  It will likely be something
> with more beads packed in with their APIs aggregated to the components API
> surface.  Folks will choose the ones they want.  But at least if you want
> to go low-level, you can.
> 
> Thanks,
> -Alex
> 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/20/16, 9:49 AM, "Harbs" <ha...@gmail.com> wrote:

>I feel like we’re not communicating. No. I want to merge as-is.

I don't understand how that would create a second component set.  Seems
like that would just stomp on the current basic set.

>
>I think that wrapping should be the default for all components. I feel
>that having Flash properties leaking though is worse than a bit of
>redirection for 99% of use cases. I can’t stress how much of an issue
>that the Flash properties and methods leaking through was for us.
>Spark-like components was not the issue. Platform-specific implementation
>details leaking through is the issue and it’s more of an issue than
>possible performance problems IMO.
>
>We have not demonstrated that the performance impact will even be an
>issue. If that’s demonstrated, we can make leaky high-preformance
>alternates for those cases.

I'll work on getting profiler information, but I have a feeling it won't
convince you.  I have proposed tool chain solutions to I think every
problem you have described.  If not, it is probably time to write down
explicit examples so everybody can understand the issue.  I must clearly
be missing something.  We have examples that work without wrapping on the
SWF-side.  The API conflicts you hit were from migrating existing Flex
code and I don't think folks starting new projects will run into the same
problems and if they want to deploy a SWF version, may be more interested
in seeing that the output has as little overhead as possible.

The URI for the basic set is currently
"library://ns.apache.org/flexjs/basic".  I don't quite get how a wrapping
pattern on the SWF-side counts as "basic".  I would offer that the
component set with wrapping have the URI
"library://ns.apache.org/flexjs/migration".  Feel free to propose an
alternate set of URIs if you are convinced your wrapping set is "basic".
I don't care that much about the names as long as the meaning is clear.
If you want the HTML.swc to contain the wrapped set, propose SWC names for
the unwrapped set.  Could be Basic.swc or BasicHTML.swc.

I have no idea what the "default" set of components will be for FlexJS.  I
doubt it will be what is currently "basic".  It will likely be something
with more beads packed in with their APIs aggregated to the components API
surface.  Folks will choose the ones they want.  But at least if you want
to go low-level, you can.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

I feel like we’re not communicating. No. I want to merge as-is.

I think that wrapping should be the default for all components. I feel that having Flash properties leaking though is worse than a bit of redirection for 99% of use cases. I can’t stress how much of an issue that the Flash properties and methods leaking through was for us. Spark-like components was not the issue. Platform-specific implementation details leaking through is the issue and it’s more of an issue than possible performance problems IMO.

We have not demonstrated that the performance impact will even be an issue. If that’s demonstrated, we can make leaky high-preformance alternates for those cases.

On Oct 20, 2016, at 7:17 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/20/16, 8:30 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> Can we just merge the sprite-refactor now and deal with the alternates
>> later (if it’s necessary)? The longer we take to merge it in, the more
>> work it will be to do so.
> 
> I assume you mean merging after moving the wrapping code into a new
> component set?  Otherwise the wrapping would overwrite the basic set.
> 
> To move the wrapping, I guess you would create another SWC or two and copy
> parts of Core and HTML?  Then revert the changes in Core and HTML that
> executed the wrapping?  There would probably be some other things to be
> fixed up after that.  I could try to help out with that.  Are there only a
> few components that "must" be wrapped like Image, or is it all components?
> 
> -Alex
> 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/20/16, 8:30 AM, "Harbs" <ha...@gmail.com> wrote:

>Can we just merge the sprite-refactor now and deal with the alternates
>later (if it’s necessary)? The longer we take to merge it in, the more
>work it will be to do so.

I assume you mean merging after moving the wrapping code into a new
component set?  Otherwise the wrapping would overwrite the basic set.

To move the wrapping, I guess you would create another SWC or two and copy
parts of Core and HTML?  Then revert the changes in Core and HTML that
executed the wrapping?  There would probably be some other things to be
fixed up after that.  I could try to help out with that.  Are there only a
few components that "must" be wrapped like Image, or is it all components?

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

Can we just merge the sprite-refactor now and deal with the alternates later (if it’s necessary)? The longer we take to merge it in, the more work it will be to do so.

On Oct 20, 2016, at 5:15 PM, Alex Harui <ah...@adobe.com> wrote:

>  But if there are advantages to wrapping the SWF side because it is the best way to ease migration that's a legitimate design decision for a different set of components.

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/20/16, 8:23 AM, "Harbs" <ha...@gmail.com> wrote:

>I don’t think so. (unless I’m misunderstanding you)
>
>I’m not sure it makes sense to have automatic overloading. Requiring
>specifying “override” when overriding a function is a good feature. It
>makes sure you don’t do it by mistake. If the Flash implementation have
>properties and methods that the JS implementation does not, that’s a
>problem because neither “override” nor regular method calls are correct.

Good point.  Subclass overloading could be controlled by a directive.

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

I don’t think so. (unless I’m misunderstanding you)

I’m not sure it makes sense to have automatic overloading. Requiring specifying “override” when overriding a function is a good feature. It makes sure you don’t do it by mistake. If the Flash implementation have properties and methods that the JS implementation does not, that’s a problem because neither “override” nor regular method calls are correct.

On Oct 20, 2016, at 5:15 PM, Alex Harui <ah...@adobe.com> wrote:

> Think of it this way: if AS did allow certain kinds of overloading, would
> you have used that instead of wrapping?

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/20/16, 1:48 AM, "Harbs" <ha...@gmail.com> wrote:

>AFAIK, properties cannot be overridden as getters and setters, so even
>simple properties can have issues. Yes. Rect Point and Matrix were all
>classes which caused problems.

This is true for now, but this is what I want to look into a bit more.
The discussion on language features and adding generics will eventually
become a discussion about allowing overloading since TS and other
languages have it.  I think I've already tweaked the compiler to allow it
for JS output.  The problem is that the SWF code can't generate a true
override because the Flash Runtime verifier won't allow it.  But I think
that the compiler might be able to actually use the base class type in the
output code and as long as the override is an extension of that type it
could work.

IOW, if you Sprite has:

  function get mask():flash.geom.Rect;

And

  class flex.geom.rect extends flash.geom.Rect;

Then if in UIBase:

  override function get mask():flex.geom.Rect

would be allowed by the compiler but it would generate

  override function get mask():flash.geom.Rect

The code inside might still do:

  return new flex.geom.Rect();

but that would be ok since it is a subclass of flash.geom.Rect.


>> Maybe the right answer is to take your sprite-wrapping and just make
>>another component set in parallel to the basic set.
>
>This makes sense to me. I’m fine with having another “optimized”
>component set if that proves to make a difference in performance, but I
>think most folks migrating code will want to use “wrapped” components to
>allow the easiest migration.

Think of it this way: if AS did allow certain kinds of overloading, would
you have used that instead of wrapping?  If so, let me see about allowing
limited overloading before we head down the path of wrapping in another
component set.  At some point, folks will aggregate often-used styles and
bead properties to the API surface and we'll have a conflict anyway.

But either way, a set of components that have more of the MX/Spark APIs
but no guarantee of the underlying infrastructure is definitely something
I wanted to see created.  Looks like it was helpful for you.  The goal of
the basic set, however, is to deliver the smallest,
close-to-native-for-that-platform output so folks who look at the
generated code don't say "Hmm, look at all that overhead, I should just
write it direct in JS or Flash".  I think the examples we have prove that
you can produce a runnable application without the overhead of wrapping
the SWF side.  But if there are advantages to wrapping the SWF side
because it is the best way to ease migration that's a legitimate design
decision for a different set of components.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

AFAIK, properties cannot be overridden as getters and setters, so even simple properties can have issues. Yes. Rect Point and Matrix were all classes which caused problems.

Transform is actually quite a bit more complicated than just CSS. For HTML, yes, you probably need CSS3. But for SVG, it’s properties, and for canvas, I think it’s methods. Right now, we only have a transform bead for SVG which uses SVG property transforms because browser support for CSS transforms is very weak.

What we ended up doing for transform was change the references from transform.matrix to transformMatrix. If our transformations were more complex, we might have needed a more complex Transform object, but we were only using 2D matrices.

> Maybe the right answer is to take your sprite-wrapping and just make another component set in parallel to the basic set.

This makes sense to me. I’m fine with having another “optimized” component set if that proves to make a difference in performance, but I think most folks migrating code will want to use “wrapped” components to allow the easiest migration.

Thanks,
Harbs

On Oct 19, 2016, at 8:07 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/19/16, 2:16 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> I don’t remember all the conflicts we had. Warnings would have helped
>> somewhat but not totally. Here’s one example (of many):
>> 
>> We were using a Sprite Image component, and we needed to migrate to a
>> FlexJS BinaryImage component. Some of the properties we were using were:
>> scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation,
>> scaleX, scaleY
>> 
>> The neatest way to migrate our code was to create a subclass of
>> BinaryImage which implements all (or rather most of) these properties and
>> use transformation, clipping, etc. beads to implement the functionality.
>> This allows all the code in our app which uses the original Spark
>> components to remain the same. Inheriting from DisplayObject (and
>> children) would make using the same properties impossible because these
>> properties are already used in Flash.
> 
> For properties that are scalars (Number, String), it is easy to override.
> But AIUI, where the type is an object like DisplayObjectContainer,
> Transform, Rect, etc, that's where it gets hard, right?  You want to
> create an org.apache.flex.geom.Transform class and make that the type of
> the "transform" property but the compiler currently won't let you do that.
> 
> FWIW, the design goal for the basic set of components was to tune it
> towards the HTML/JS platform.  It was not a priority to maintain and
> emulate Flash API surfaces.  I did choose to do so for
> x,y,width,height,visible, but didn't really want to propagate properties
> for every other Sprite API.  Taking a quick look this morning, I see that
> for HTML/JS, transform is a CSS property.  Thus, I would not have chosen
> to treat transform as a property in a FlexJS image component.  It would
> remain a style and specified in MXML like we specify other styles, and a
> bead would pick up the style and "do the right thing" on the SWF side.
> Then you probably wouldn't have hit an API conflict.  And then, the JS
> would run as optimally as it could because the developer could specify the
> transform in CSS and no code at runtime on the JS side would have to apply
> it.  The browser would just see the DOM and the CSS and "do it".
> 
> That said, when someone got around to emulating the Spark components they
> would have eventually hit this same problem, but for emulating Spark, the
> infrastructure is so fat anyway, wrapping could be an plausible option.
> But IIRC, there still is a pain point for something as simple as the
> parent property.  And I think there were some issues with Rectangles in
> APIs as well, but I'm not sure.
> 
> Basically, my experience from Flex is that, as you add code to make a
> perfect world, you end up tempting others to undercut you with lighter
> weight frameworks and fracture the community.  I want FlexJS to own the
> lowest-level so everybody builds on top of it.  Tools should be able to
> give you the developer productivity without having to pay for it at
> runtime.  I spent a great deal of time profiling for folks who were just
> about to go production and realized that their app had grown too fat and
> slow.  
> 
> Choosing to emulate Flash APIs creates more conflicts and is less optimal
> for the JS side, but does mean there is more migration work to do.  Maybe
> the right answer is to take your sprite-wrapping and just make another
> component set in parallel to the basic set.  There is certainly an option
> for someone to make a "not-quite-full-emulation" or "less-migration" set
> of components for FlexJS that is someplace between the basic set and the
> full Spark/MX port.  It would be interesting to see how many beads like
> the disabled bead could be used for both component sets.
> 
> -Alex
> 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/19/16, 2:16 AM, "Harbs" <ha...@gmail.com> wrote:

>I don’t remember all the conflicts we had. Warnings would have helped
>somewhat but not totally. Here’s one example (of many):
>
>We were using a Sprite Image component, and we needed to migrate to a
>FlexJS BinaryImage component. Some of the properties we were using were:
>scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation,
>scaleX, scaleY
>
>The neatest way to migrate our code was to create a subclass of
>BinaryImage which implements all (or rather most of) these properties and
>use transformation, clipping, etc. beads to implement the functionality.
>This allows all the code in our app which uses the original Spark
>components to remain the same. Inheriting from DisplayObject (and
>children) would make using the same properties impossible because these
>properties are already used in Flash.

For properties that are scalars (Number, String), it is easy to override.
But AIUI, where the type is an object like DisplayObjectContainer,
Transform, Rect, etc, that's where it gets hard, right?  You want to
create an org.apache.flex.geom.Transform class and make that the type of
the "transform" property but the compiler currently won't let you do that.

FWIW, the design goal for the basic set of components was to tune it
towards the HTML/JS platform.  It was not a priority to maintain and
emulate Flash API surfaces.  I did choose to do so for
x,y,width,height,visible, but didn't really want to propagate properties
for every other Sprite API.  Taking a quick look this morning, I see that
for HTML/JS, transform is a CSS property.  Thus, I would not have chosen
to treat transform as a property in a FlexJS image component.  It would
remain a style and specified in MXML like we specify other styles, and a
bead would pick up the style and "do the right thing" on the SWF side.
Then you probably wouldn't have hit an API conflict.  And then, the JS
would run as optimally as it could because the developer could specify the
transform in CSS and no code at runtime on the JS side would have to apply
it.  The browser would just see the DOM and the CSS and "do it".

That said, when someone got around to emulating the Spark components they
would have eventually hit this same problem, but for emulating Spark, the
infrastructure is so fat anyway, wrapping could be an plausible option.
But IIRC, there still is a pain point for something as simple as the
parent property.  And I think there were some issues with Rectangles in
APIs as well, but I'm not sure.

Basically, my experience from Flex is that, as you add code to make a
perfect world, you end up tempting others to undercut you with lighter
weight frameworks and fracture the community.  I want FlexJS to own the
lowest-level so everybody builds on top of it.  Tools should be able to
give you the developer productivity without having to pay for it at
runtime.  I spent a great deal of time profiling for folks who were just
about to go production and realized that their app had grown too fat and
slow.  

Choosing to emulate Flash APIs creates more conflicts and is less optimal
for the JS side, but does mean there is more migration work to do.  Maybe
the right answer is to take your sprite-wrapping and just make another
component set in parallel to the basic set.  There is certainly an option
for someone to make a "not-quite-full-emulation" or "less-migration" set
of components for FlexJS that is someplace between the basic set and the
full Spark/MX port.  It would be interesting to see how many beads like
the disabled bead could be used for both component sets.

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/19/16, 8:35 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>"Despite the fact that we’re putting an emphasis on HTML performance, HTML
>objects are wrapped. (I think it’s a completely reasonable approach for
>HTML.) This causes none of the HTML APIs to leak through. The same should
>apply to Flash objects and any other future platforms we might have in the
>future."
>
>I was already leaning toward agreeing with Harbs, and this argument only
>cements it more strongly for me.

The only reason HTML objects are wrapped is because I don't know of any
other way to create a subclassing model that MXML uses.  IOW, if you could
extend HTMLButtonElement and instantiate it via "new
MyHTMLButtonElement()" the JS side would not have HTMLElementWrapper at
all.  I considered __proto__ hacking, but ruled it out.  I could certainly
be wrong, but I would be surprised if whatever new hot platform we want to
target someday doesn't have an object-oriented extension API.

I've watched as document.createEvent("MouseEvents") has been deprecated in
favor of "new MouseEvent()".  If the browsers ever did the same for
document.createElement, I would want to unwrap the JS code.  The wrapping
was not done to present a cleaner API to developers.  I would want the
tools to present the cleaner API, but let the implementation be as optimal
as possible.

That is, however, hard to do today, especially for the SWF version, since
the verifier doesn't allow subclass overrides.  So maybe we will just have
to live with wrapping both JS and SWF sides for now, but I'd like to
explore having the tools allow subclass overrides before we give up.  For
the SWF implementation, wrapping potentially means that we can't leverage
the runtime's event model and have to build out our own.

-Alex

>
>- Josh
>
>On Wed, Oct 19, 2016 at 2:16 AM, Harbs <ha...@gmail.com> wrote:
>
>> Despite the fact that we’re putting an emphasis on HTML performance,
>>HTML
>> objects are wrapped. (I think it’s a completely reasonable approach for
>> HTML.) This causes none of the HTML APIs to leak through. The same
>>should
>> apply to Flash objects and any other future platforms we might have in
>>the
>> future. If there’s cases where this causes performance problems, I
>>think it
>> can be dealt with in a case-by-case basis.
>>
>> I think it would be great to show conflicts against platform-specific
>> implementations, but I think we should keep those to a minimum.
>>
>> I don’t remember all the conflicts we had. Warnings would have helped
>> somewhat but not totally. Here’s one example (of many):
>>
>> We were using a Sprite Image component, and we needed to migrate to a
>> FlexJS BinaryImage component. Some of the properties we were using were:
>> scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation,
>> scaleX, scaleY
>>
>> The neatest way to migrate our code was to create a subclass of
>> BinaryImage which implements all (or rather most of) these properties
>>and
>> use transformation, clipping, etc. beads to implement the functionality.
>> This allows all the code in our app which uses the original Spark
>> components to remain the same. Inheriting from DisplayObject (and
>>children)
>> would make using the same properties impossible because these properties
>> are already used in Flash.
>>
>> On Oct 18, 2016, at 8:52 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> >
>> >
>> > On 10/18/16, 10:26 AM, "Harbs" <ha...@gmail.com> wrote:
>> >
>> >>
>> >> On Oct 18, 2016, at 7:30 PM, Alex Harui <ah...@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> OK, I think you are describing a different problem.  AIUI, you are
>> saying
>> >>> that certain APIs cannot currently be overridden or overloaded to
>>take
>> a
>> >>> subclass or alternate type.  That you can't override
>>Sprite.transform
>> to
>> >>> take a org.apache.flexjs.Transform.  I could look into getting the
>> >>> compiler to accept overrides/overloads.  I thought I'd done some of
>> that
>> >>> already.
>> >>
>> >> This is the main problem I was having. It’s not just “overriding”.
>>The
>> >> HTML side of things do not have the properties defined at all. The
>>Flash
>> >> ones have the properties, and they are used in a possibly different
>>way
>> >> than you would use them. Events are a problem that’s somewhat
>>related to
>> >> this, but not exactly. Basically, Flash is limiting how we can
>>implement
>> >> things for HTML output, and I think that’s a bad thing.
>> >
>> > The decision on whether to wrap or not will impact how we implement
>> events.
>> >
>> > Yes, we are putting an emphasis on HTML output and its size and
>> > performance and are willing to make some sacrifices on the SWF size
>>and
>> > performance, but as I mentioned recently in another thread, we do
>>want to
>> > leave the door open to a third platform some day.  That means to me
>>that
>> > we really want to enable building a framework that targets multiple
>> > platforms in as low a level as we can, and use the tooling to show
>>folks
>> > the common APIs they should use, and the conflicts against the
>> > platform-specific implementations.  The alternative, which is to
>>always
>> > seek abstractions that have more commonality, is a viable direction,
>>but
>> I
>> > think we are here because the overhead of doing so was prohibitive to
>> > creating small fast apps.
>> >
>> > Also, looking down the road, the recent discussion about language
>> features
>> > implies that we will need to implement some type of overloading.
>> >
>> > So, I would like to understand where the really painful places are
>>where
>> > Flash is getting in the way and see if starting down the path of
>> > supporting overloading will get us around it.  You mentioned
>> > Sprite.transform.  Can you provide more detail on that scenario?  I
>>think
>> > Sprite.parent may be one.  And I think there were some issues are
>> > Rectangle and Point as well?
>> >
>> >>
>> >>
>> >>>
>> >>>>
>> >>>>> Animations pound on x,y,width,height as does layout.
>> >>>>
>> >>>> So what? If there’s a specific case which is performant sensitive,
>>the
>> >>>> Flash implementation can manipulate the underlying Flash objects
>> >>>> directly.
>> >>>>
>> >>>> I really believe that composition is the better solution
>> >>>> architecturally
>> >>>> (as it’s doing for the HTML side). I’d like to see some proof that
>> >>>> there’s a memory usage issue with using composition, and I believe
>> >>>> performance issue which might come up can be dealt with (by using
>>SWF
>> >>>> code blocks and addressing the $displayObject properties directly).
>> >>>
>> >>> What would be the pattern for optimization?  Without
>>tail-optimization,
>> >>> I
>> >>> don't see how you can reduce function calls.  IOW, when I set
>> >>> Button.width, it will set element.width.  How do you get
>>Button.width
>> to
>> >>> directly set the Sprite's width in a COMPILE::SWF block?
>> >>
>> >> The underlying DisplayObjects are available for direct access in a
>>SWF
>> >> block. I expect most code which would need optimization to be in
>> >> Framework code, so instead of calling Button.width, you’d call
>> >> Button.$displayObject.width. Currently, $displayObject is a getter,
>>but
>> >> if that proves to be a performance problem, it could easily be
>>converted
>> >> to a simple property.
>> >>
>> >> Yes, you have an extra property reference (i.e. $displayObject), but
>>I
>> >> find it hard to believe that’s going to be an issue. Even if it is
>>(i.e.
>> >> in a tight loop), the DisplayObject reference can likely be cached.
>> >>
>> >> Does this sound reasonable?
>> >
>> > IMO, we want the entire framework to have as few SWF-specific code
>>paths
>> > as possible.  Lots of layouts and effects can be written without
>> > conditional compilation and thus the optimization you suggest
>>wouldn't be
>> > available.
>> >
>> > Thanks,
>> > -Alex
>>
>>

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Josh Tynjala <jo...@gmail.com>]

"Despite the fact that we’re putting an emphasis on HTML performance, HTML
objects are wrapped. (I think it’s a completely reasonable approach for
HTML.) This causes none of the HTML APIs to leak through. The same should
apply to Flash objects and any other future platforms we might have in the
future."

I was already leaning toward agreeing with Harbs, and this argument only
cements it more strongly for me.

- Josh

On Wed, Oct 19, 2016 at 2:16 AM, Harbs <ha...@gmail.com> wrote:

> Despite the fact that we’re putting an emphasis on HTML performance, HTML
> objects are wrapped. (I think it’s a completely reasonable approach for
> HTML.) This causes none of the HTML APIs to leak through. The same should
> apply to Flash objects and any other future platforms we might have in the
> future. If there’s cases where this causes performance problems, I think it
> can be dealt with in a case-by-case basis.
>
> I think it would be great to show conflicts against platform-specific
> implementations, but I think we should keep those to a minimum.
>
> I don’t remember all the conflicts we had. Warnings would have helped
> somewhat but not totally. Here’s one example (of many):
>
> We were using a Sprite Image component, and we needed to migrate to a
> FlexJS BinaryImage component. Some of the properties we were using were:
> scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation,
> scaleX, scaleY
>
> The neatest way to migrate our code was to create a subclass of
> BinaryImage which implements all (or rather most of) these properties and
> use transformation, clipping, etc. beads to implement the functionality.
> This allows all the code in our app which uses the original Spark
> components to remain the same. Inheriting from DisplayObject (and children)
> would make using the same properties impossible because these properties
> are already used in Flash.
>
> On Oct 18, 2016, at 8:52 PM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> > On 10/18/16, 10:26 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >>
> >> On Oct 18, 2016, at 7:30 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>>
> >>>
> >>> OK, I think you are describing a different problem.  AIUI, you are
> saying
> >>> that certain APIs cannot currently be overridden or overloaded to take
> a
> >>> subclass or alternate type.  That you can't override Sprite.transform
> to
> >>> take a org.apache.flexjs.Transform.  I could look into getting the
> >>> compiler to accept overrides/overloads.  I thought I'd done some of
> that
> >>> already.
> >>
> >> This is the main problem I was having. It’s not just “overriding”. The
> >> HTML side of things do not have the properties defined at all. The Flash
> >> ones have the properties, and they are used in a possibly different way
> >> than you would use them. Events are a problem that’s somewhat related to
> >> this, but not exactly. Basically, Flash is limiting how we can implement
> >> things for HTML output, and I think that’s a bad thing.
> >
> > The decision on whether to wrap or not will impact how we implement
> events.
> >
> > Yes, we are putting an emphasis on HTML output and its size and
> > performance and are willing to make some sacrifices on the SWF size and
> > performance, but as I mentioned recently in another thread, we do want to
> > leave the door open to a third platform some day.  That means to me that
> > we really want to enable building a framework that targets multiple
> > platforms in as low a level as we can, and use the tooling to show folks
> > the common APIs they should use, and the conflicts against the
> > platform-specific implementations.  The alternative, which is to always
> > seek abstractions that have more commonality, is a viable direction, but
> I
> > think we are here because the overhead of doing so was prohibitive to
> > creating small fast apps.
> >
> > Also, looking down the road, the recent discussion about language
> features
> > implies that we will need to implement some type of overloading.
> >
> > So, I would like to understand where the really painful places are where
> > Flash is getting in the way and see if starting down the path of
> > supporting overloading will get us around it.  You mentioned
> > Sprite.transform.  Can you provide more detail on that scenario?  I think
> > Sprite.parent may be one.  And I think there were some issues are
> > Rectangle and Point as well?
> >
> >>
> >>
> >>>
> >>>>
> >>>>> Animations pound on x,y,width,height as does layout.
> >>>>
> >>>> So what? If there’s a specific case which is performant sensitive, the
> >>>> Flash implementation can manipulate the underlying Flash objects
> >>>> directly.
> >>>>
> >>>> I really believe that composition is the better solution
> >>>> architecturally
> >>>> (as it’s doing for the HTML side). I’d like to see some proof that
> >>>> there’s a memory usage issue with using composition, and I believe
> >>>> performance issue which might come up can be dealt with (by using SWF
> >>>> code blocks and addressing the $displayObject properties directly).
> >>>
> >>> What would be the pattern for optimization?  Without tail-optimization,
> >>> I
> >>> don't see how you can reduce function calls.  IOW, when I set
> >>> Button.width, it will set element.width.  How do you get Button.width
> to
> >>> directly set the Sprite's width in a COMPILE::SWF block?
> >>
> >> The underlying DisplayObjects are available for direct access in a SWF
> >> block. I expect most code which would need optimization to be in
> >> Framework code, so instead of calling Button.width, you’d call
> >> Button.$displayObject.width. Currently, $displayObject is a getter, but
> >> if that proves to be a performance problem, it could easily be converted
> >> to a simple property.
> >>
> >> Yes, you have an extra property reference (i.e. $displayObject), but I
> >> find it hard to believe that’s going to be an issue. Even if it is (i.e.
> >> in a tight loop), the DisplayObject reference can likely be cached.
> >>
> >> Does this sound reasonable?
> >
> > IMO, we want the entire framework to have as few SWF-specific code paths
> > as possible.  Lots of layouts and effects can be written without
> > conditional compilation and thus the optimization you suggest wouldn't be
> > available.
> >
> > Thanks,
> > -Alex
>
>

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

This should obviously have been Spark instead of Sprite…

On Oct 19, 2016, at 12:16 PM, Harbs <ha...@gmail.com> wrote:

> We were using a Sprite Image component

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

Despite the fact that we’re putting an emphasis on HTML performance, HTML objects are wrapped. (I think it’s a completely reasonable approach for HTML.) This causes none of the HTML APIs to leak through. The same should apply to Flash objects and any other future platforms we might have in the future. If there’s cases where this causes performance problems, I think it can be dealt with in a case-by-case basis.

I think it would be great to show conflicts against platform-specific implementations, but I think we should keep those to a minimum.

I don’t remember all the conflicts we had. Warnings would have helped somewhat but not totally. Here’s one example (of many):

We were using a Sprite Image component, and we needed to migrate to a FlexJS BinaryImage component. Some of the properties we were using were:
scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation, scaleX, scaleY

The neatest way to migrate our code was to create a subclass of BinaryImage which implements all (or rather most of) these properties and use transformation, clipping, etc. beads to implement the functionality. This allows all the code in our app which uses the original Spark components to remain the same. Inheriting from DisplayObject (and children) would make using the same properties impossible because these properties are already used in Flash.

On Oct 18, 2016, at 8:52 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/18/16, 10:26 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> 
>> On Oct 18, 2016, at 7:30 PM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> 
>>> 
>>> OK, I think you are describing a different problem.  AIUI, you are saying
>>> that certain APIs cannot currently be overridden or overloaded to take a
>>> subclass or alternate type.  That you can't override Sprite.transform to
>>> take a org.apache.flexjs.Transform.  I could look into getting the
>>> compiler to accept overrides/overloads.  I thought I'd done some of that
>>> already.
>> 
>> This is the main problem I was having. It’s not just “overriding”. The
>> HTML side of things do not have the properties defined at all. The Flash
>> ones have the properties, and they are used in a possibly different way
>> than you would use them. Events are a problem that’s somewhat related to
>> this, but not exactly. Basically, Flash is limiting how we can implement
>> things for HTML output, and I think that’s a bad thing.
> 
> The decision on whether to wrap or not will impact how we implement events.
> 
> Yes, we are putting an emphasis on HTML output and its size and
> performance and are willing to make some sacrifices on the SWF size and
> performance, but as I mentioned recently in another thread, we do want to
> leave the door open to a third platform some day.  That means to me that
> we really want to enable building a framework that targets multiple
> platforms in as low a level as we can, and use the tooling to show folks
> the common APIs they should use, and the conflicts against the
> platform-specific implementations.  The alternative, which is to always
> seek abstractions that have more commonality, is a viable direction, but I
> think we are here because the overhead of doing so was prohibitive to
> creating small fast apps.
> 
> Also, looking down the road, the recent discussion about language features
> implies that we will need to implement some type of overloading.
> 
> So, I would like to understand where the really painful places are where
> Flash is getting in the way and see if starting down the path of
> supporting overloading will get us around it.  You mentioned
> Sprite.transform.  Can you provide more detail on that scenario?  I think
> Sprite.parent may be one.  And I think there were some issues are
> Rectangle and Point as well?
> 
>> 
>> 
>>> 
>>>> 
>>>>> Animations pound on x,y,width,height as does layout.
>>>> 
>>>> So what? If there’s a specific case which is performant sensitive, the
>>>> Flash implementation can manipulate the underlying Flash objects
>>>> directly.
>>>> 
>>>> I really believe that composition is the better solution
>>>> architecturally
>>>> (as it’s doing for the HTML side). I’d like to see some proof that
>>>> there’s a memory usage issue with using composition, and I believe
>>>> performance issue which might come up can be dealt with (by using SWF
>>>> code blocks and addressing the $displayObject properties directly).
>>> 
>>> What would be the pattern for optimization?  Without tail-optimization,
>>> I
>>> don't see how you can reduce function calls.  IOW, when I set
>>> Button.width, it will set element.width.  How do you get Button.width to
>>> directly set the Sprite's width in a COMPILE::SWF block?
>> 
>> The underlying DisplayObjects are available for direct access in a SWF
>> block. I expect most code which would need optimization to be in
>> Framework code, so instead of calling Button.width, you’d call
>> Button.$displayObject.width. Currently, $displayObject is a getter, but
>> if that proves to be a performance problem, it could easily be converted
>> to a simple property.
>> 
>> Yes, you have an extra property reference (i.e. $displayObject), but I
>> find it hard to believe that’s going to be an issue. Even if it is (i.e.
>> in a tight loop), the DisplayObject reference can likely be cached.
>> 
>> Does this sound reasonable?
> 
> IMO, we want the entire framework to have as few SWF-specific code paths
> as possible.  Lots of layouts and effects can be written without
> conditional compilation and thus the optimization you suggest wouldn't be
> available.
> 
> Thanks,
> -Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/18/16, 10:26 AM, "Harbs" <ha...@gmail.com> wrote:

>
>On Oct 18, 2016, at 7:30 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> 
>> 
>>OK, I think you are describing a different problem.  AIUI, you are saying
>> that certain APIs cannot currently be overridden or overloaded to take a
>> subclass or alternate type.  That you can't override Sprite.transform to
>> take a org.apache.flexjs.Transform.  I could look into getting the
>> compiler to accept overrides/overloads.  I thought I'd done some of that
>> already.
>
>This is the main problem I was having. It’s not just “overriding”. The
>HTML side of things do not have the properties defined at all. The Flash
>ones have the properties, and they are used in a possibly different way
>than you would use them. Events are a problem that’s somewhat related to
>this, but not exactly. Basically, Flash is limiting how we can implement
>things for HTML output, and I think that’s a bad thing.

The decision on whether to wrap or not will impact how we implement events.

Yes, we are putting an emphasis on HTML output and its size and
performance and are willing to make some sacrifices on the SWF size and
performance, but as I mentioned recently in another thread, we do want to
leave the door open to a third platform some day.  That means to me that
we really want to enable building a framework that targets multiple
platforms in as low a level as we can, and use the tooling to show folks
the common APIs they should use, and the conflicts against the
platform-specific implementations.  The alternative, which is to always
seek abstractions that have more commonality, is a viable direction, but I
think we are here because the overhead of doing so was prohibitive to
creating small fast apps.

Also, looking down the road, the recent discussion about language features
implies that we will need to implement some type of overloading.

So, I would like to understand where the really painful places are where
Flash is getting in the way and see if starting down the path of
supporting overloading will get us around it.  You mentioned
Sprite.transform.  Can you provide more detail on that scenario?  I think
Sprite.parent may be one.  And I think there were some issues are
Rectangle and Point as well?

>
>
>> 
>>> 
>>>> Animations pound on x,y,width,height as does layout.
>>> 
>>> So what? If there’s a specific case which is performant sensitive, the
>>> Flash implementation can manipulate the underlying Flash objects
>>>directly.
>>> 
>>> I really believe that composition is the better solution
>>>architecturally
>>> (as it’s doing for the HTML side). I’d like to see some proof that
>>> there’s a memory usage issue with using composition, and I believe
>>> performance issue which might come up can be dealt with (by using SWF
>>> code blocks and addressing the $displayObject properties directly).
>> 
>> What would be the pattern for optimization?  Without tail-optimization,
>>I
>> don't see how you can reduce function calls.  IOW, when I set
>> Button.width, it will set element.width.  How do you get Button.width to
>> directly set the Sprite's width in a COMPILE::SWF block?
>
>The underlying DisplayObjects are available for direct access in a SWF
>block. I expect most code which would need optimization to be in
>Framework code, so instead of calling Button.width, you’d call
>Button.$displayObject.width. Currently, $displayObject is a getter, but
>if that proves to be a performance problem, it could easily be converted
>to a simple property.
>
>Yes, you have an extra property reference (i.e. $displayObject), but I
>find it hard to believe that’s going to be an issue. Even if it is (i.e.
>in a tight loop), the DisplayObject reference can likely be cached.
>
>Does this sound reasonable?

IMO, we want the entire framework to have as few SWF-specific code paths
as possible.  Lots of layouts and effects can be written without
conditional compilation and thus the optimization you suggest wouldn't be
available.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

On Oct 18, 2016, at 7:30 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/18/16, 9:08 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>>> Why are you objecting to using a tooling workflow to find the potential
>>> conflicts of your code against the various platform implementations?
>> 
>> Because I don’t think it’s just a tooling problem.
>> 
>> Basically, you are suggesting that there should be tooling to warn the
>> user that certain properties or methods are not allowed because one or
>> more platforms use the names. (Or rename them.)
> 
> Yes.  Unless we ensure that the API surface of every component is the same
> for every platform (currently just SWF and JS), some day you will hit a
> conflict.  IMO it is best to have the tooling workflow catch this ASAP.
> Setting up two projects in FB should work for now.  Getting the FB
> integration to launch both compilers so you only need one project would be
> a future enhancement.

Tooling is not a bad thing, and catching problems on all platforms is a good goal, but most of the Flash problems should not exist to start with.

>> 
>> Not allowing top specify myObj.transform (for example) because Flash uses
>> transform is unintuitive and unnecessarily limiting. It also requires a
>> specific tool chain for it to work. Automatically renaming properties
>> seems like a hack to me and seems like it will have unexpected side
>> effects. Also: there’s the question of how to you choose which
>> “transform” to use in your code — the Flash one or the custom one.
> 
> OK, I think you are describing a different problem.  AIUI, you are saying
> that certain APIs cannot currently be overridden or overloaded to take a
> subclass or alternate type.  That you can't override Sprite.transform to
> take a org.apache.flexjs.Transform.  I could look into getting the
> compiler to accept overrides/overloads.  I thought I'd done some of that
> already.

This is the main problem I was having. It’s not just “overriding”. The HTML side of things do not have the properties defined at all. The Flash ones have the properties, and they are used in a possibly different way than you would use them. Events are a problem that’s somewhat related to this, but not exactly. Basically, Flash is limiting how we can implement things for HTML output, and I think that’s a bad thing.


> 
>> 
>>> Animations pound on x,y,width,height as does layout.
>> 
>> So what? If there’s a specific case which is performant sensitive, the
>> Flash implementation can manipulate the underlying Flash objects directly.
>> 
>> I really believe that composition is the better solution architecturally
>> (as it’s doing for the HTML side). I’d like to see some proof that
>> there’s a memory usage issue with using composition, and I believe
>> performance issue which might come up can be dealt with (by using SWF
>> code blocks and addressing the $displayObject properties directly).
> 
> What would be the pattern for optimization?  Without tail-optimization, I
> don't see how you can reduce function calls.  IOW, when I set
> Button.width, it will set element.width.  How do you get Button.width to
> directly set the Sprite's width in a COMPILE::SWF block?

The underlying DisplayObjects are available for direct access in a SWF block. I expect most code which would need optimization to be in Framework code, so instead of calling Button.width, you’d call Button.$displayObject.width. Currently, $displayObject is a getter, but if that proves to be a performance problem, it could easily be converted to a simple property.

Yes, you have an extra property reference (i.e. $displayObject), but I find it hard to believe that’s going to be an issue. Even if it is (i.e. in a tight loop), the DisplayObject reference can likely be cached.

Does this sound reasonable?

> -Alex
> 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/18/16, 9:08 AM, "Harbs" <ha...@gmail.com> wrote:

>> Why are you objecting to using a tooling workflow to find the potential
>> conflicts of your code against the various platform implementations?
>
>Because I don’t think it’s just a tooling problem.
>
>Basically, you are suggesting that there should be tooling to warn the
>user that certain properties or methods are not allowed because one or
>more platforms use the names. (Or rename them.)

Yes.  Unless we ensure that the API surface of every component is the same
for every platform (currently just SWF and JS), some day you will hit a
conflict.  IMO it is best to have the tooling workflow catch this ASAP.
Setting up two projects in FB should work for now.  Getting the FB
integration to launch both compilers so you only need one project would be
a future enhancement.

>
>Not allowing top specify myObj.transform (for example) because Flash uses
>transform is unintuitive and unnecessarily limiting. It also requires a
>specific tool chain for it to work. Automatically renaming properties
>seems like a hack to me and seems like it will have unexpected side
>effects. Also: there’s the question of how to you choose which
>“transform” to use in your code — the Flash one or the custom one.

OK, I think you are describing a different problem.  AIUI, you are saying
that certain APIs cannot currently be overridden or overloaded to take a
subclass or alternate type.  That you can't override Sprite.transform to
take a org.apache.flexjs.Transform.  I could look into getting the
compiler to accept overrides/overloads.  I thought I'd done some of that
already.

>
>> Animations pound on x,y,width,height as does layout.
>
>So what? If there’s a specific case which is performant sensitive, the
>Flash implementation can manipulate the underlying Flash objects directly.
>
>I really believe that composition is the better solution architecturally
>(as it’s doing for the HTML side). I’d like to see some proof that
>there’s a memory usage issue with using composition, and I believe
>performance issue which might come up can be dealt with (by using SWF
>code blocks and addressing the $displayObject properties directly).

What would be the pattern for optimization?  Without tail-optimization, I
don't see how you can reduce function calls.  IOW, when I set
Button.width, it will set element.width.  How do you get Button.width to
directly set the Sprite's width in a COMPILE::SWF block?

-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

> Why are you objecting to using a tooling workflow to find the potential
> conflicts of your code against the various platform implementations?

Because I don’t think it’s just a tooling problem.

Basically, you are suggesting that there should be tooling to warn the user that certain properties or methods are not allowed because one or more platforms use the names. (Or rename them.)

Not allowing top specify myObj.transform (for example) because Flash uses transform is unintuitive and unnecessarily limiting. It also requires a specific tool chain for it to work. Automatically renaming properties seems like a hack to me and seems like it will have unexpected side effects. Also: there’s the question of how to you choose which “transform” to use in your code — the Flash one or the custom one.

> Animations pound on x,y,width,height as does layout.

So what? If there’s a specific case which is performant sensitive, the Flash implementation can manipulate the underlying Flash objects directly.

I really believe that composition is the better solution architecturally (as it’s doing for the HTML side). I’d like to see some proof that there’s a memory usage issue with using composition, and I believe performance issue which might come up can be dealt with (by using SWF code blocks and addressing the $displayObject properties directly).

On Oct 18, 2016, at 6:33 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 10/18/16, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> I’m not sure where this response went…
>> 
>> On Sep 29, 2016, at 9:15 AM, Harbs <ha...@gmail.com> wrote:
>> 
>>> Let’s actually do some profiling so we can see if there’s really an
>>> issue.
>>> 
>>> Is there really a difference whether you have one object whose size is
>>> x+y or two objects where one size is x and another is y?
>>> 
>>> I doubt there’s anywhere close to twice as many function calls. Yes.
>>> For setting native Flash properties there will be double setters and
>>> getters, but that’s not going to be the majority of the code being run
>>> and we might be able to optimize those calls in certain cases if it’s an
>>> issue.
> 
> Why are you objecting to using a tooling workflow to find the potential
> conflicts of your code against the various platform implementations?
> There is a separate discussion of being able to compile against both
> platforms from a single IDE project.  IMO, that would be best because
> there can be other platform-specific things not related to the wrapping
> that can conflict against your code.
> 
> Again, the "oh, it's just a little bit of extra code" is what cause Flex
> to have a 13,000 line UIComponent and a 130K hello world.  Please let us
> use the tool chain to find the conflicts and not burden the production
> code.  Animations pound on x,y,width,height as does layout.
> 
> Thanks,
> -Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 10/18/16, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:

>I’m not sure where this response went…
>
>On Sep 29, 2016, at 9:15 AM, Harbs <ha...@gmail.com> wrote:
>
>> Let’s actually do some profiling so we can see if there’s really an
>>issue.
>> 
>> Is there really a difference whether you have one object whose size is
>>x+y or two objects where one size is x and another is y?
>> 
>> I doubt there’s anywhere close to twice as many function calls. Yes.
>>For setting native Flash properties there will be double setters and
>>getters, but that’s not going to be the majority of the code being run
>>and we might be able to optimize those calls in certain cases if it’s an
>>issue.

Why are you objecting to using a tooling workflow to find the potential
conflicts of your code against the various platform implementations?
There is a separate discussion of being able to compile against both
platforms from a single IDE project.  IMO, that would be best because
there can be other platform-specific things not related to the wrapping
that can conflict against your code.

Again, the "oh, it's just a little bit of extra code" is what cause Flex
to have a 13,000 line UIComponent and a 130K hello world.  Please let us
use the tool chain to find the conflicts and not burden the production
code.  Animations pound on x,y,width,height as does layout.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

I’m not sure where this response went…

On Sep 29, 2016, at 9:15 AM, Harbs <ha...@gmail.com> wrote:

> Let’s actually do some profiling so we can see if there’s really an issue.
> 
> Is there really a difference whether you have one object whose size is x+y or two objects where one size is x and another is y?
> 
> I doubt there’s anywhere close to twice as many function calls. Yes. For setting native Flash properties there will be double setters and getters, but that’s not going to be the majority of the code being run and we might be able to optimize those calls in certain cases if it’s an issue.
> 
> On Sep 29, 2016, at 12:42 AM, Alex Harui <ah...@adobe.com> wrote:
> 
>> I could put the code
>> through a profiler, but my understanding is that the refactor creates
>> twice as many objects and probably at least twice as many function calls
>> at runtime.
> 

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 12:21 AM, "Harbs" <ha...@gmail.com> wrote:

>The overhead to swfs seem to me like it’s really minimal. There’s not a
>lot of added code for using composition rather than inheritance.

Well, at Adobe, we said "the overhead is minimal" so many times in Flex
that UIComponent grew to 13,000 lines of code.  I could put the code
through a profiler, but my understanding is that the refactor creates
twice as many objects and probably at least twice as many function calls
at runtime.  Yes, we will accept bigger sizes and slower performance on
the SWF side in order to make sure the JS side is as efficient as
possible, but IMO, we aren't wrapping Sprite to help the JS side.

>
>Improving events is probably something which should be done for the JS
>side as well, so I’m not convinced that’s a major problem either. Some of
>the event issues we had had nothing to do with inheritance vs composition
>of Sprite and friends. It had to do with the fact that MouseEvent and
>Event are unrelated.

Yup, and once we decide on the sprite refactor we can then decide on how
to deal with events.

>
>Additionally, I really don’t believe most folks will use swf output for
>much more than debugging purposes, so if there’s a little more overhead,
>so what?

Ideally, the SWF version would remain viable for deployment so folks who
can use Flash can continue to save on cross-browser testing, but also, we
need big apps to load the SWF version fast enough to make it efficient to
use as a debugging version.  Doubling objects and function calls isn't
going to help.


>We’ve also done a lot of work on the sprite-refactor branch which would
>be hard to back-port.

I would think if we abandon the sprite wrapping, we would revert UIBase
and Application to extend Sprite in the refactor branch, then the branch
merge to develop would pick up everything else.

IMO, if it were easy to upgrade every Flex IDE, we would solve the issue
of detecting which Flash APIs aren't available by modifying the IDEs.
This means to me that it isn't required to solve this problem by making
changes to the runtime output.

Today, I played with a "new workflow" for migrating apps that might solve
this problem for FB and maybe other IDEs.  I created a test app called
"NewFlexJSProject" and selected FlexJS as the SDK.  It looked like this:

<js:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
                   xmlns:js="library://ns.apache.org/flexjs/basic" >
    <fx:Script>
        <![CDATA[
            override public function get buttonMode():Boolean
            {
                return super.buttonMode;
            }
        ]]>
    </fx:Script>
...
</js:Application>

As you can see it overrides the buttonMode setter on Sprite, which isn't
supported by FlexJS.  AIUI, this is typical of the kinds of problems you
ran into.  The SWF version compiles just fine.


Next, I created another Flex project and made the application look like
this:

<js:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
                xmlns:js="library://ns.apache.org/flexjs/basic" >
    <fx:Script>
        <![CDATA[
            private var test:NewFlexJSProject = new NewFlexJSProject;
        ]]>
    </fx:Script>
</js:Application>

I set the source path to point to NewFlexJSProject/src, then I modified
the library-path to remove the standard FlexJS SWCs and playerglobal, then
add in the js.swc from js/libs and the SWC folder from
frameworks/js/FlexJS/libs.  That folder contains xxxJS.swc that present
the JS-side APIs to downstream SWCs.


When I did that, this project showed errors about buttonMode in
NewFlexJSProject.mxml.

IMO, a workflow like this might be sufficient for speeding up migration
without requiring the extra overhead of wrapping Sprite.  We could
possibly teach our compilers to compile twice, once with each library path
so you don't have to set up the second project.  That's why I believe
there are ways to solve the problem of catching use of Sprite APIs without
wrapping Sprite and making all SWFs pay the price via the tool chain and
not code running at runtime.

Thoughts?
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs <ha...@gmail.com>]

The overhead to swfs seem to me like it’s really minimal. There’s not a lot of added code for using composition rather than inheritance.

Improving events is probably something which should be done for the JS side as well, so I’m not convinced that’s a major problem either. Some of the event issues we had had nothing to do with inheritance vs composition of Sprite and friends. It had to do with the fact that MouseEvent and Event are unrelated.

Additionally, I really don’t believe most folks will use swf output for much more than debugging purposes, so if there’s a little more overhead, so what?

Yes. Method and attribute conflicts were a major problem for us. This is especially true for code which is migrated from Flash. You get no compiler warnings, but things do not work as expected.

We’ve also done a lot of work on the sprite-refactor branch which would be hard to back-port.

In short, I think we should stick with composition and deal with the few issues it causes.

On Sep 27, 2016, at 10:43 PM, Alex Harui <ah...@adobe.com> wrote:

> Probably time to re-open this debate...
> 
> As I understand it, there are 3 issues:
> 
> 1.  When migrating code, it is important to where your code is relying on
> Flash APIs that aren't supported by FlexJS, but if UIBase extends Sprite
> the compiler will happily let your code make calls to Sprite APIs.
> 
> 2.  In code completion in Flash Builder and maybe other IDEs, lots of
> non-FlexJS APIs are offered.
> 
> 3.  When migrating code, an override of a SWF-only API will result in a
> compile error when compiling for JS since that API has no base class
> implementation on the JS side.  And vice versa.
> 
> Wrapping Sprite solves all of these problems, but introduces new ones like
> the need for a new event subsystem, and adds runtime and download overhead
> to every SWF.  I would rather solve these problems in the compiler so
> there is no runtime overhead.
> 
> Here are my latest thoughts:
> 
> A) We could require the exact same API surfaces on both SWF and JS but
> that seems like excessive overhead.  Would it be so bad if your code might
> run into a compile error during the JS compile if the SWF compile comes
> out clean?  I think that's a reasonable price to pay so everyone doesn't
> have to pay download and runtime overhead.
> B) I don't use Flash Builder code completion myself since I pretty much
> know the APIs.  When folks use it, do they want all public APIs or would
> they really want the list to be filtered to "usable" APIs.  For example,
> in Flex UIComponent, there are public APIs like the "initialized" property
> that application developers should not be setting.  I'm wondering if we
> should create different SWCs that have different APIs filtered on ASDoc
> directives so the "application" version of the SWC doesn't show APIs you
> shouldn't be using in building your app.  Of course, when you finally
> output something to run, you may still get errors if you used APIs we hid
> from you.  Having filters in ASDoc would also help ASDoc filter away APIs
> most folks won't need.
> 
> Thoughts?
> 
> -Alex
>