I think there should be two separate value sets. There should be set values and inferred values.
Currently FlexJS is relying WAY too much on the browser to get and set values. Case in point: We just profiled our app and using the VerticalLayout, are relatively simple layout was taking about 250ms to lay out. Switching the VerticalFlexLayout got that time down to about 70ms. However, there are still lots of DOM calls in ContainerView and 70ms is still a lot. The browser should only be used to getting and setting values when *absolutely* necessary. I would vote for the default x and y values to be the SET ones and have another measuredX and measuredY to get the values set by the browser for cases where that’s important (which I think is a lot more rare than is currently assumed). My $0.02. Harbs > On Mar 1, 2017, at 3:56 PM, Peter Ent <p...@adobe.com> wrote: > > I think we have confusion over what FlexJS is trying to deliver. If we are > trying to make a new Flex that works on both HTML/JS and SWF platforms, > that, to me, implies SWF is the preferred platform and we need to make > HTML/JS platform conform to it. Thus the coordinate system needs to > reflect that. > > If we are trying to make it possible to use ActionScript and MXML to build > apps that run on HTML/JS platform primarily with SWF being a good way to > debug and to also run efficiently, then we need to make clean JS code and > write code to support/mimic that on SWF. > > I don't see how it can be both ways. The coordinate systems are very > different and even on HTML/JS, you can get different values depending on > the box-sizing model being used. Keep in mind that HTML/JS was not > designed to be an application UI platform which is why tech like Flash, > Canvas, Java, etc. came along (among many other reasons). > > This confusion is reflected currently in the code (large portions of this > layout and container were written by yours truly). I believe our intention > is to make HTML/JS the standard and make SWF mimic it as closely as > possible. However, UI application developers, whether they come from > Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0 and > read x back as 10. I am not a JavaScript developer so I don't know what JS > folks come to expect and how they work with this coordinate system. Maybe > most of the UI is static and the apps just use form fields for input and > effects are set up in CSS and then triggered so programmatic manipulation > of object position is rare; I don't know. > > But I do know this must be resolved and made consistent before we can have > a first true release. If that means adding nested divs to adjust > coordinates to make x=0 read back x as zero despite padding and margin, > then we'll do that. Or if it means you need to be aware of padding and > margin when reading back values, we can do that. We can also introduce new > getters (e.g., absoluteX and absoluteY to be x,y without margin and > padding). > > There are a bunch of options and I'm sorry this wasn't resolved a long > time ago, but as I said, bridging these platforms is difficult and we have > lots of good stuff written, we just need to shore up the foundation to > make it tight. > > Regards, > Peter > > On 3/1/17, 4:07 AM, "Fréderic Cox" <coxfrede...@gmail.com> wrote: > >> Isn't this what localToGlobal etc.. did for Flex? >> >> Personally I would like testButton.x to return 0 in all instances. Unless >> I >> want it's actual screen position where I use the helper functions like >> localToGlobal etc.. >> >> On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <p...@adobe.com> wrote: >> >>> Hi, >>> >>> In an effort to clean up Container and layouts, we need to look at the >>> coordinate system of FlexJS. Since the goal is to have the SWF side >>> mimic >>> the JS side, perhaps we should visit the "coordinate system" of HTML. >>> You'll find an Apache Paste at [1] below. If you could run that and make >>> any changes you'd like and see what you think. >>> >>> Basically: in Flex 4 and Flash, when you position something at (0,0) and >>> you read its x coordinates back, it is at (0,0). In HTML land, that >>> isn't >>> exactly how it works. There are several things that influence the >>> position >>> of an element: the position style of its parent, the padding of its >>> parent, >>> the margin style of the element and the position style of the element. >>> >>> If you set a div to have a padding of 10 and an element to have >>> position:relative with left:0 it will appear 10 pixels from the left >>> edge >>> of the div. That's what would expect. However, if you try to read that >>> element's position, you need to use its read-only property, offsetLeft. >>> That value will be 10, not 0. >>> >>> How would you feel if FlexJS worked the same way? >>> >>> <js:Container> >>> <js:style> >>> <js:SimpleCSSStyles padding="10" /> >>> </js:style> >>> <js:TextButton id="testButton" x="0" y="0" /> >>> </js:Container> >>> >>> When you ask for testButton's x or y values it would return 10 due to >>> the >>> padding on its Container parent. >>> >>> Right now Container has this inner contentArea that tries to make sure >>> testButton is (0,0) but it is a headache to maintain, I think. >>> >>> [1] https://paste.apache.org/IM1W >>> >>> Regards, >>> Peter Ent >>> Adobe Systems/Apache Flex Project >>> >
