Well, you changed the test a bit. I guess I should have had child show a
border. Where would the border be? And isn't child.offsetParent !=
child.parentNode?
Also shouldn't the test be:
var point:Point = PointUtils.localToGlobal(new Point(0, 0),child);
Also, I don't remember if Group defaults to BasicLayout or not and what code
BasicLayout ran.
But aren't you saying that the label shows up in an unexpected place? I think
we know where the label would show up in Flex (30,30). What code will make
both the label and border show up correctly in Royale, or should we give up on
that working like Flex? I think this may be why early FlexJS did set
position!=static throughout the DOM.
I would hope we could find a way to get these scenarios to work like Flex. I
think to get it to work, we need parent.style.position=relative instead of
child.style.position=relative? I'm still wondering if BasicLayout and/or the
x,y setters should set parentNode.style.positon!=static. Then I think we could
drop the offsetParent check.
Thoughts?
-Alex
On 6/7/18, 4:25 PM, "Harbs" <harbs.li...@gmail.com> wrote:
I was waiting to test it.
Here’s the results:
<?xml version="1.0" encoding="utf-8"?>
<js:Application
xmlns:fx="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7Cf2a842aed6694578539708d5cccdfc59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636640107452777321&sdata=j0vYBh5Vanfu5s6VWv4MK9iaG%2FuUgqAgTYzP44HpfAU%3D&reserved=0";
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.
>
