I'm not arguing to keep this code and much as make sure it is right. I did
ponder removing x,y from Royale. But I think x,y should exist for backward
compatibility. And if it is going to exist, then it should work like it did in
Flex. Which means setting x,y to the offset you expect from the component's
parent (is that what you mean by "observed"). But if the actual offsetParent
is something else, then code needs to factor that in. I don't think we want
folks to have to consider how the browser and offsetParent work internally.
Maybe I'm not fully understanding the problem. Let's say that you have:
<Application>
<Group id="parent" style="padding:10px">
<Group id="child" x="20" y="20" />
</Group>
</Application>
I think this produces a DOM like this:
<body>
<div id="parent" style="padding:10px">
<div id="child" style="left:20px;top:20px">
</div>
</div>
</body>
AIUI, with the changes you propose, the child Group will be 20 pixels in from
the body, not 30. But in Flex it would be at 30. That's because the
offsetParent for child is body. Some legacy testing code might verify that
localToGlobal(child.x) == 30. Will it with your proposed changes?
More inline...
On 6/7/18, 2:32 PM, "Harbs" <harbs.li...@gmail.com> wrote:
The only case it will not work is if three conditions are fulfilled:
1. The x value started off being undefined and you do someWidget.x += 10;
2. The offsetParent is not the parent.
3. The element is offset from the offsetParent at some value other than 0.
#1 is invalid. X cannot be undefined. That would be a bug if it is. It
should return 0 if it has never been touched.
#2 I would think that offsetParent != parentNode in most of the DOM elements in
RoyaleStore or any example. If not, why not?
#3 I thought padding would offset the element so most elements in our examples
have an offsetLeft/Top != 0
I have yet to find a case where this is a problem. If there is, then by all
means, I’d like to know, but I’m willing to bet there’s some way of fixing it
other than paying for that code in UIBase.
For sure, I'm not a big fan of the old code either, I'm just having trouble
believing it isn't needed.
> It is not PAYG to worry about the performance of an API that is rarely
used. That is how PAYG works. You pay for it when you use it. If you can
lower the cost without making everyone pay for it, great, but the most
important principle is that you cannot make everyone pay for it just-in-case.
Migrating apps may pay more in order to change less code, but AIUI, the trend
in UI design in general is to get away from absolute positioning and use
flexbox and CSSGrid in order to have responsive UIs, so I don't see x,y
performance as important.
I did a lot of profiling. Trust me. It’s important. It’s the single-largest
performance bottleneck I’ve found in Royale apps. Sometimes, you can improve it
by being smarter about where you set x and y values, but not always. It effects
every use of x=“” and y=“” used in MXML. The vast majority of apps will have
some x and y value somewhere.
Of course if you profile lots of changes to x,y it will be a big performance
bottleneck. My point is that with the trend for responsive UI, there should be
much fewer, if any, changes to x,y so it shouldn't matter how slow that code
is. I think we disagree as to how often x,y will be set. I would still like
to know why folks need to set it in so many places in their UI.
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.
> 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?
Thanks,
-Alex
