royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?
Date Fri, 08 Jun 2018 07:40:32 GMT

> On Jun 8, 2018, at 2:47 AM, Alex Harui <aharui@adobe.com.INVALID> wrote:
> 
> 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);

That would be 10 with or without the parentOffset code.

> 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.

Yes. That was probably why. Does it show in an unexpected place? Maybe. It depends on what
you call unexpected.

Maybe a Group should have a default layout of “Relative” or something. I think it’s
fair to say that an emulation component set should set the default to relative.

> 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?

No. It’s child. Left and top values have no effect on elements which are static.

>  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.

We can drop the offsetParent check either way, but maybe non-static should be set. I really
would not want that code to be in the x and y setters though unless it could be made *really*
cheap. I suppose we could have a “position” property on UIBase which could be used to
determine whether non-static needs to be set. The position setter could be overridden in component
sets to allow for inline styles vs css selectors.

The most PAYG way to handle this is probably with a bead which adds the global position: relative
selector. That approach should work fine as long as the app is the body. If we ever add support
to inserting a Royale app into a div on a page, the global selector might cause unexpected
effects on the rest of the page which might rely on the default position: static setting.

> 
> Thoughts?
> -Alex
> 
> On 6/7/18, 4:25 PM, "Harbs" <harbs.lists@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 <aharui@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.lists@gmail.com> wrote:
>> 
>> 
>>> On Jun 8, 2018, at 1:11 AM, Alex Harui <aharui@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.
>> 
> 
> 
> 


Mime
View raw message