I was waiting to test it. Here’s the results:
<?xml version="1.0" encoding="utf-8"?> <js:Application xmlns:fx="http://ns.adobe.com/mxml/2009"; xmlns:js="library://ns.apache.org/royale/basic" xmlns:ns1="*" applicationComplete="onComplete()" > <fx:Script> <![CDATA[ import org.apache.royale.utils.PointUtils; import org.apache.royale.geom.Point; private function onComplete():void{ var point:Point = PointUtils.localToGlobal(new Point(child.x,child.y),child); trace(point); } ]]> </fx:Script> <js:valuesImpl> <js:SimpleCSSValuesImpl /> </js:valuesImpl> <js:initialView> <js:View> <js:Group id="parent" style="padding:10px"> <js:Group id="child" x="20" y="20"> <js:Label text="Hello"/> </js:Group> </js:Group> </js:View> </js:initialView> </js:Application> Traces: org.apache.royale.geom.Point {x: 30, y: 30} I think that’s the result you wanted. As to why: because it adds 20 to the bounding box of the element which is 10,10. Mind you: The *visual* placement of the word Hello is actually 10,10 rather than 30,30, but the *logical* placement of it is 30,30. The reason is because the x and y values have no effect. To make the visual placement match the logical placement, the position of “child” needs to be changed to relative. Harbs > On Jun 8, 2018, at 1:50 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Harbs, > > I posted a 3 MXML tag example. Will it work like it does in Flex with your > changes? If so, how/why? > > If not, then we need the old code. It is unfortunate that it causes extra > reflows, but setting x,y should be rare. And if you can propose a different > solution that is PAYG, even better. I keep wondering if we should go back to > setting position!=static on the parentNode when x,y is set. > > The scenario where offsetParent changes also needs to be understood to know > how rare it is or if it is a result of some other bug. We have to be careful > about spending lots of time on these cases if they are corner cases or a > side-effect. > > All I'm trying to do is make sure your analysis and proposed changes are > correct. There have been scenarios cited (RoyaleStore) and solutions > proposed (Application * selector0 that weren't valid so I'm just trying to > help make sure this is right. It just isn't making sense to me that > offsetParent doesn't matter in the x,y calculation or that there is framework > code that changes offsetParent. I don't want to worry about the performance > of x,y being set if most UI really shouldn't be setting it. But for sure, it > has to produce the right values. > > Thanks, > -Alex > > On 6/7/18, 3:26 PM, "Harbs" <harbs.li...@gmail.com> wrote: > > >> On Jun 8, 2018, at 1:11 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> In your animation code example, having the offsetParent code in the setter >> makes the animation *way* less efficient. There is a an extra forced reflow >> for every assignment of the new value. >> >> I don't understand this point. Can you provide more detail? I would >> imagine animations are going to cause reflows. If there is a way to do >> animations without resulting in a reflow that would be great. > > The point is that there is a forced reflow. There will definitely be a > reflow when the browser draws the animation change, but the offsetParent code > forces the browser to calculate an extra reflow during the code execution > prior to setting the x value. > > This has two problems: > 1. There is two reflows per cycle instead of one. If the animation sets > both x and y values, there will be three reflows (the first two forced) > instead of one. > 2. The first reflow is forced to happen during javascript execution rather > than when the browser decides it’s the optimum time to do so. > >> >>> I think you are saying there is a bug in the current code, but it somehow >>> involves offsetParent changing. Can you explain what causes offsetParent >>> to change? >> >> If/when the parent (or grandparent or great-grandparent, etc.) element >> position changes from static to some other value, the offsetParent will >> change. >> >> Again, how important/prevalent is such a scenario? > > It’s hard to say, but one such scenario sparked this discussion. I think > that avoiding lifecycle issues is pretty important. >
