You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/02/07 08:43:05 UTC
What is x and y? What is width and height?
Hi,
In Royale on JS, we are trying to leverage the browser's layout code as
much as possible. We only run our own layout code in a few places.
In debugging a few layout issues I discovered that UIBase is not reporting
x and y the way we expect it from Flex/Flash. Browser elements don't have
x and y properties, instead they have offsetLeft and offsetTop. Mainly
for backward-compatibility with Flex/Flash, Royale has had x and y in the
API since the beginning. I think it is a bug that x and y do not act like
they do in Flex and plan to fix that after this release. Thoughts? I'm a
bit concerned of the expense of calculating x and y because you have to
check if the offsetParent is your immediate parent and get the
offsetLeft/offsetTop of the immediate parent, but I think that's what it
would take to fix it.
Similarly (well, sort of), Flex did not support CSS margins, only padding.
The browser reports width (offsetWidth) as factoring in content, padding
and borders, but not margin. I think that's right, and matches Flex.
However, our custom layout algorithms do not currently factor in margins
since they are not reported in width. I think our custom layout should
request width and margins and do the math. We should not change width to
include margins. Thoughts? This will make our custom layout code a bit
more expensive as well as it will probably need to call
getComputedStyles() on all of the children in order to get margins. This
is also something to fix in the next release.
Of course, I could be wrong. Thoughts?
-Alex
Re: What is x and y? What is width and height?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hmm. Maybe we need to understand the circumstances. It makes no sense to
me to have x,y return useless values just because it is easy or fast to
do. The main point is that in the HTML/JS/CSS world there is no x,y
values so we can make them do anything we want, but do we want it to work
like Flex/Flash? I think so.
Clearly, most of our examples and applications don't care about x,y
otherwise we would have hit this earlier. Or maybe we've worked around it
in the few places we've hit it. Fixing it is unlikely to cause apps to
have performance issues. Basically, there are going to be scenarios where
we don't want the browser to run its normal layout. One example is in
ASDoc where you have a 3-pane UI with scrollbars. There is no way to make
that work with display:flex in some browsers. But the scenario I just ran
into was floating a popup or dropdown underneath some UI widget. Right
now, checking the widget's x,y will not return the right value. I think
it should, no matter how long it takes to compute it. Another scenario I
expect us to hit more often is when we run effects. That also tends to
float UI widgets and position them.
Under PAYG, we might have default code that expects that nothing is
transformed and even slower code if transforms are in play.
The issue about width is different from the issue about x,y. Do we want
width to factor in margins or not? And, independent of that, do we accept
that we must call getComputedStyles() if width hasn't been otherwise set
in order to return the right value?
Thoughts?
-Alex
On 2/7/18, 8:40 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>Can you post into the separate thread if it's even possible any of those
>case ?
>
>2018-02-07 17:36 GMT+01:00 Gabe Harbs <ha...@gmail.com>:
>
>> Yes. Flexbox solves a lot of problems, and I use the “flex” layouts
>>pretty
>> extensively.
>>
>> However, I have run into lots of cases which are hard to solve and the
>>old
>> Flex-style layouts would have been helpful.
>>
>> > On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki <pi...@gmail.com>
>> wrote:
>> >
>> > Lately I had huge exercises with FlexBox mechanism and it is finally
>> > something. I have never seen better working things in HTML than this.
>>If
>> I
>> > wanted to make elements on the right they are really displays on the
>> right.
>> > - Without FlexBox I would be nowhere.
>> >
>> > Maybe it is not the answer for the constrained layout, but it is
>> something.
>> >
>> > Thanks,
>> > Piotr
>> >
>> > 2018-02-07 17:24 GMT+01:00 Gabe Harbs <ha...@gmail.com>:
>> >
>> >> FWIW, I do think we need a “constrained layout” which places
>> *everything*
>> >> absolutely and does not rely on browser layout. If that layout were
>>to
>> be
>> >> used, the bounding box values would be correct.
>> >>
>> >>> On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID>
>>wrote:
>> >>>
>> >>> I think I agree with Harbs about x,y,width,height just returning the
>> set
>> >>> values if the calculation would be expensive. I wonder what the
>> >>> circumstances are that we actually need to have precise values in
>> >>> calculations. For example, if I wanted to make a circulate layout,
>>how
>> >>> would I go about doing that?
>> >>>
>> >>> In the places I've done layouts without regard to platform I'm just
>> >>> assuming things work. For example, in the DataGridLayout, I need to
>> >>> transfer the column width given on the js:DataGridColumn definition
>>to
>> >>> both the List (column) and the corresponding Button in the
>>ButtonBar.
>> >>> Ideally, the browser takes that (along with display and position
>> styles)
>> >>> and just does the right thing with minimum code on our part (that's
>>not
>> >>> actually what I'm doing, so perhaps I should rethink that one more
>> time).
>> >>>
>> >>> ‹peter
>> >>>
>> >>> On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>> >>>
>> >>>> The offset values are very expensive.
>> >>>>
>> >>>> They are also not completely accurate. I¹ve found it¹s difficult to
>> get
>> >>>> accurate values where SVG and transforms are in play.
>> >>>>
>> >>>> I would suggest that x,y,widht and height should reflect *set*
>>values
>> >>>> even if they are not always the actual ones.
>> >>>>
>> >>>> For cases where it¹s necessary to get accurate measured x,y,width
>>and
>> >>>> height, I would suggest using ³measured² variations of these
>>values,
>> or
>> >>>> better, a getMeasuredBounds() method.
>> >>>>
>> >>>>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
>> >>>>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> In Royale on JS, we are trying to leverage the browser's layout
>>code
>> as
>> >>>>> much as possible. We only run our own layout code in a few
>>places.
>> >>>>> In debugging a few layout issues I discovered that UIBase is not
>> >>>>> reporting
>> >>>>> x and y the way we expect it from Flex/Flash. Browser elements
>>don't
>> >>>>> have
>> >>>>> x and y properties, instead they have offsetLeft and offsetTop.
>> Mainly
>> >>>>> for backward-compatibility with Flex/Flash, Royale has had x and
>>y in
>> >>>>> the
>> >>>>> API since the beginning. I think it is a bug that x and y do not
>>act
>> >>>>> like
>> >>>>> they do in Flex and plan to fix that after this release.
>>Thoughts?
>> >>>>> I'm a
>> >>>>> bit concerned of the expense of calculating x and y because you
>>have
>> to
>> >>>>> check if the offsetParent is your immediate parent and get the
>> >>>>> offsetLeft/offsetTop of the immediate parent, but I think that's
>>what
>> >> it
>> >>>>> would take to fix it.
>> >>>>>
>> >>>>> Similarly (well, sort of), Flex did not support CSS margins, only
>> >>>>> padding.
>> >>>>> The browser reports width (offsetWidth) as factoring in content,
>> >> padding
>> >>>>> and borders, but not margin. I think that's right, and matches
>>Flex.
>> >>>>> However, our custom layout algorithms do not currently factor in
>> >> margins
>> >>>>> since they are not reported in width. I think our custom layout
>> should
>> >>>>> request width and margins and do the math. We should not change
>> width
>> >>>>> to
>> >>>>> include margins. Thoughts? This will make our custom layout
>>code a
>> >> bit
>> >>>>> more expensive as well as it will probably need to call
>> >>>>> getComputedStyles() on all of the children in order to get
>>margins.
>> >>>>> This
>> >>>>> is also something to fix in the next release.
>> >>>>>
>> >>>>> Of course, I could be wrong. Thoughts?
>> >>>>>
>> >>>>> -Alex
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Piotr Zarzycki
>> >
>> > Patreon:
>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f41564
>>4cf8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361
>>84438193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&rese
>>rved=0
>> >
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f41564
>>4cf8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361
>>84438193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&rese
>>rved=0>*
>>
>>
>
>
>--
>
>Piotr Zarzycki
>
>Patreon:
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f415644c
>f8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361844
>38193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&reserved
>=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f415644c
>f8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361844
>38193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&reserved
>=0>*
Re: What is x and y? What is width and height?
Posted by Piotr Zarzycki <pi...@gmail.com>.
Can you post into the separate thread if it's even possible any of those
case ?
2018-02-07 17:36 GMT+01:00 Gabe Harbs <ha...@gmail.com>:
> Yes. Flexbox solves a lot of problems, and I use the “flex” layouts pretty
> extensively.
>
> However, I have run into lots of cases which are hard to solve and the old
> Flex-style layouts would have been helpful.
>
> > On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki <pi...@gmail.com>
> wrote:
> >
> > Lately I had huge exercises with FlexBox mechanism and it is finally
> > something. I have never seen better working things in HTML than this. If
> I
> > wanted to make elements on the right they are really displays on the
> right.
> > - Without FlexBox I would be nowhere.
> >
> > Maybe it is not the answer for the constrained layout, but it is
> something.
> >
> > Thanks,
> > Piotr
> >
> > 2018-02-07 17:24 GMT+01:00 Gabe Harbs <ha...@gmail.com>:
> >
> >> FWIW, I do think we need a “constrained layout” which places
> *everything*
> >> absolutely and does not rely on browser layout. If that layout were to
> be
> >> used, the bounding box values would be correct.
> >>
> >>> On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
> >>>
> >>> I think I agree with Harbs about x,y,width,height just returning the
> set
> >>> values if the calculation would be expensive. I wonder what the
> >>> circumstances are that we actually need to have precise values in
> >>> calculations. For example, if I wanted to make a circulate layout, how
> >>> would I go about doing that?
> >>>
> >>> In the places I've done layouts without regard to platform I'm just
> >>> assuming things work. For example, in the DataGridLayout, I need to
> >>> transfer the column width given on the js:DataGridColumn definition to
> >>> both the List (column) and the corresponding Button in the ButtonBar.
> >>> Ideally, the browser takes that (along with display and position
> styles)
> >>> and just does the right thing with minimum code on our part (that's not
> >>> actually what I'm doing, so perhaps I should rethink that one more
> time).
> >>>
> >>> ‹peter
> >>>
> >>> On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> >>>
> >>>> The offset values are very expensive.
> >>>>
> >>>> They are also not completely accurate. I¹ve found it¹s difficult to
> get
> >>>> accurate values where SVG and transforms are in play.
> >>>>
> >>>> I would suggest that x,y,widht and height should reflect *set* values
> >>>> even if they are not always the actual ones.
> >>>>
> >>>> For cases where it¹s necessary to get accurate measured x,y,width and
> >>>> height, I would suggest using ³measured² variations of these values,
> or
> >>>> better, a getMeasuredBounds() method.
> >>>>
> >>>>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> >>>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> In Royale on JS, we are trying to leverage the browser's layout code
> as
> >>>>> much as possible. We only run our own layout code in a few places.
> >>>>> In debugging a few layout issues I discovered that UIBase is not
> >>>>> reporting
> >>>>> x and y the way we expect it from Flex/Flash. Browser elements don't
> >>>>> have
> >>>>> x and y properties, instead they have offsetLeft and offsetTop.
> Mainly
> >>>>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>>>> the
> >>>>> API since the beginning. I think it is a bug that x and y do not act
> >>>>> like
> >>>>> they do in Flex and plan to fix that after this release. Thoughts?
> >>>>> I'm a
> >>>>> bit concerned of the expense of calculating x and y because you have
> to
> >>>>> check if the offsetParent is your immediate parent and get the
> >>>>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> >> it
> >>>>> would take to fix it.
> >>>>>
> >>>>> Similarly (well, sort of), Flex did not support CSS margins, only
> >>>>> padding.
> >>>>> The browser reports width (offsetWidth) as factoring in content,
> >> padding
> >>>>> and borders, but not margin. I think that's right, and matches Flex.
> >>>>> However, our custom layout algorithms do not currently factor in
> >> margins
> >>>>> since they are not reported in width. I think our custom layout
> should
> >>>>> request width and margins and do the math. We should not change
> width
> >>>>> to
> >>>>> include margins. Thoughts? This will make our custom layout code a
> >> bit
> >>>>> more expensive as well as it will probably need to call
> >>>>> getComputedStyles() on all of the children in order to get margins.
> >>>>> This
> >>>>> is also something to fix in the next release.
> >>>>>
> >>>>> Of course, I could be wrong. Thoughts?
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: What is x and y? What is width and height?
Posted by Gabe Harbs <ha...@gmail.com>.
Yes. Flexbox solves a lot of problems, and I use the “flex” layouts pretty extensively.
However, I have run into lots of cases which are hard to solve and the old Flex-style layouts would have been helpful.
> On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki <pi...@gmail.com> wrote:
>
> Lately I had huge exercises with FlexBox mechanism and it is finally
> something. I have never seen better working things in HTML than this. If I
> wanted to make elements on the right they are really displays on the right.
> - Without FlexBox I would be nowhere.
>
> Maybe it is not the answer for the constrained layout, but it is something.
>
> Thanks,
> Piotr
>
> 2018-02-07 17:24 GMT+01:00 Gabe Harbs <ha...@gmail.com>:
>
>> FWIW, I do think we need a “constrained layout” which places *everything*
>> absolutely and does not rely on browser layout. If that layout were to be
>> used, the bounding box values would be correct.
>>
>>> On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>>>
>>> I think I agree with Harbs about x,y,width,height just returning the set
>>> values if the calculation would be expensive. I wonder what the
>>> circumstances are that we actually need to have precise values in
>>> calculations. For example, if I wanted to make a circulate layout, how
>>> would I go about doing that?
>>>
>>> In the places I've done layouts without regard to platform I'm just
>>> assuming things work. For example, in the DataGridLayout, I need to
>>> transfer the column width given on the js:DataGridColumn definition to
>>> both the List (column) and the corresponding Button in the ButtonBar.
>>> Ideally, the browser takes that (along with display and position styles)
>>> and just does the right thing with minimum code on our part (that's not
>>> actually what I'm doing, so perhaps I should rethink that one more time).
>>>
>>> ‹peter
>>>
>>> On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>>>
>>>> The offset values are very expensive.
>>>>
>>>> They are also not completely accurate. I¹ve found it¹s difficult to get
>>>> accurate values where SVG and transforms are in play.
>>>>
>>>> I would suggest that x,y,widht and height should reflect *set* values
>>>> even if they are not always the actual ones.
>>>>
>>>> For cases where it¹s necessary to get accurate measured x,y,width and
>>>> height, I would suggest using ³measured² variations of these values, or
>>>> better, a getMeasuredBounds() method.
>>>>
>>>>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> In Royale on JS, we are trying to leverage the browser's layout code as
>>>>> much as possible. We only run our own layout code in a few places.
>>>>> In debugging a few layout issues I discovered that UIBase is not
>>>>> reporting
>>>>> x and y the way we expect it from Flex/Flash. Browser elements don't
>>>>> have
>>>>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
>>>>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>>>> the
>>>>> API since the beginning. I think it is a bug that x and y do not act
>>>>> like
>>>>> they do in Flex and plan to fix that after this release. Thoughts?
>>>>> I'm a
>>>>> bit concerned of the expense of calculating x and y because you have to
>>>>> check if the offsetParent is your immediate parent and get the
>>>>> offsetLeft/offsetTop of the immediate parent, but I think that's what
>> it
>>>>> would take to fix it.
>>>>>
>>>>> Similarly (well, sort of), Flex did not support CSS margins, only
>>>>> padding.
>>>>> The browser reports width (offsetWidth) as factoring in content,
>> padding
>>>>> and borders, but not margin. I think that's right, and matches Flex.
>>>>> However, our custom layout algorithms do not currently factor in
>> margins
>>>>> since they are not reported in width. I think our custom layout should
>>>>> request width and margins and do the math. We should not change width
>>>>> to
>>>>> include margins. Thoughts? This will make our custom layout code a
>> bit
>>>>> more expensive as well as it will probably need to call
>>>>> getComputedStyles() on all of the children in order to get margins.
>>>>> This
>>>>> is also something to fix in the next release.
>>>>>
>>>>> Of course, I could be wrong. Thoughts?
>>>>>
>>>>> -Alex
>>>>>
>>>>
>>>
>>
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
Re: What is x and y? What is width and height?
Posted by Piotr Zarzycki <pi...@gmail.com>.
Lately I had huge exercises with FlexBox mechanism and it is finally
something. I have never seen better working things in HTML than this. If I
wanted to make elements on the right they are really displays on the right.
- Without FlexBox I would be nowhere.
Maybe it is not the answer for the constrained layout, but it is something.
Thanks,
Piotr
2018-02-07 17:24 GMT+01:00 Gabe Harbs <ha...@gmail.com>:
> FWIW, I do think we need a “constrained layout” which places *everything*
> absolutely and does not rely on browser layout. If that layout were to be
> used, the bounding box values would be correct.
>
> > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
> >
> > I think I agree with Harbs about x,y,width,height just returning the set
> > values if the calculation would be expensive. I wonder what the
> > circumstances are that we actually need to have precise values in
> > calculations. For example, if I wanted to make a circulate layout, how
> > would I go about doing that?
> >
> > In the places I've done layouts without regard to platform I'm just
> > assuming things work. For example, in the DataGridLayout, I need to
> > transfer the column width given on the js:DataGridColumn definition to
> > both the List (column) and the corresponding Button in the ButtonBar.
> > Ideally, the browser takes that (along with display and position styles)
> > and just does the right thing with minimum code on our part (that's not
> > actually what I'm doing, so perhaps I should rethink that one more time).
> >
> > ‹peter
> >
> > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> >
> >> The offset values are very expensive.
> >>
> >> They are also not completely accurate. I¹ve found it¹s difficult to get
> >> accurate values where SVG and transforms are in play.
> >>
> >> I would suggest that x,y,widht and height should reflect *set* values
> >> even if they are not always the actual ones.
> >>
> >> For cases where it¹s necessary to get accurate measured x,y,width and
> >> height, I would suggest using ³measured² variations of these values, or
> >> better, a getMeasuredBounds() method.
> >>
> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In Royale on JS, we are trying to leverage the browser's layout code as
> >>> much as possible. We only run our own layout code in a few places.
> >>> In debugging a few layout issues I discovered that UIBase is not
> >>> reporting
> >>> x and y the way we expect it from Flex/Flash. Browser elements don't
> >>> have
> >>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
> >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>> the
> >>> API since the beginning. I think it is a bug that x and y do not act
> >>> like
> >>> they do in Flex and plan to fix that after this release. Thoughts?
> >>> I'm a
> >>> bit concerned of the expense of calculating x and y because you have to
> >>> check if the offsetParent is your immediate parent and get the
> >>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> it
> >>> would take to fix it.
> >>>
> >>> Similarly (well, sort of), Flex did not support CSS margins, only
> >>> padding.
> >>> The browser reports width (offsetWidth) as factoring in content,
> padding
> >>> and borders, but not margin. I think that's right, and matches Flex.
> >>> However, our custom layout algorithms do not currently factor in
> margins
> >>> since they are not reported in width. I think our custom layout should
> >>> request width and margins and do the math. We should not change width
> >>> to
> >>> include margins. Thoughts? This will make our custom layout code a
> bit
> >>> more expensive as well as it will probably need to call
> >>> getComputedStyles() on all of the children in order to get margins.
> >>> This
> >>> is also something to fix in the next release.
> >>>
> >>> Of course, I could be wrong. Thoughts?
> >>>
> >>> -Alex
> >>>
> >>
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: What is x and y? What is width and height?
Posted by Harbs <ha...@gmail.com>.
VerticalColumnLayout is a perfect example of potential performance problems with x and y setters and getters. The layout method has the following code inside a loop (which turns out to take a measurable amount of time):
e.x = curx + data[i].ml;
e.y = cury + data[i].mt;
curx += columns[col++];
maxHeight = Math.max(maxHeight, e.y + e.height + data[i].mb);
maxWidth = Math.max(maxWidth, e.x + e.width + data[i].mr);
If first sets the x and y values and then reads those same values. As it stands, that’s two DOM writes and two DOM reads per iteration (ignoring the width and height getters for the moment). There’s no reason why these operations need to be so expensive when it could simply return a private var when possible.
My $0.02,
Harbs
> On Mar 26, 2018, at 12:00 PM, Harbs <ha...@gmail.com> wrote:
>
> I just bumped into this same issue.
>
> It’s actually worse than this:
>
> Imagine you have an element whose parent node has an offsetLeft of 10 from its offsetParent.
>
> If the x value was not set at all, the returned value from the x getter will be 0.
> If you set the x to 0, the returned value will now become 10!
>
> This is because the x getter subtracts the parent offsetLeft when calculating the value, but blindly returns the style value if it was set.
>
> That’s clearly wrong.
>
> It seems clear to me that the x and y setters and getters should be setting a private x and y value which should be set and returned if applicable, so 0 will be returned in both cases.
>
> If someone wants to know what the measured x and or y is, they could use utility functions for that. We already have localToGlobal.
>
> I’d like to implement this change if we’re in agreement.
>
> My $0.02
> Harbs
>
>> On Feb 8, 2018, at 9:10 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>
>> In most cases we do output the most basic code. But let's look at one
>> scenario I expect to run into more than once, which is placing a popup
>> somewhere.
>>
>> Like I said, in most of our code, we rarely read back x and y. I don't
>> even think we read x and y in an absolute positioning container. But I
>> would imagine there is a fair number of places in existing Flex apps that
>> do something like:
>>
>> // center tooltip horizontally
>> Var tt:FancyToolTip = new FancyToolTip();
>> ...
>> tt.x = MyWidget.x + MyWidget.width / 2.
>>
>> This simple example does not work today. I am proposing it should work
>> for non-transformed UI. I think we can make it work. We can provide
>> alternative ways of doing it by abstracting the calculation into utility
>> functions but it just seems strange to me that UI widgets should not have
>> x,y properties that work like they do in Flex/Flash. But you are right,
>> we do have the option of not having x,y on our UI widgets.
>>
>> Another scenario may be as we write more effects. They may have similar
>> issues picking starting points. I think this might be an issue of how
>> easy we make it for folks to migrate. The calculation for x and y is just
>> subtracting the container's offsetLeft or offsetTop from the component's
>> offsetLeft or offsetTop so one extra read of a property. Of course, I
>> could be wrong about that.
>>
>> My 2 cents,
>> -Alex
>>
>> On 2/8/18, 10:45 AM, "carlos.rovira@gmail.com <ma...@gmail.com> on behalf of Carlos Rovira"
>> <carlos.rovira@gmail.com <ma...@gmail.com> on behalf of carlosrovira@apache.org <ma...@apache.org>> wrote:
>>
>>> Hi Alex,
>>>
>>> in this case it's hard to prove this will be a problem. Maybe the apps
>>> will
>>> suffer it very slightly for most people to perceive it, but that's not the
>>> problem. The problem is our solution will have additional calculations
>>> *always* that other frameworks doesn't have. And that's goes against our
>>> principle in JS to output the most basic js code we can since we'll end
>>> with some strange code only introduced to match a developer time way of
>>> doing things.
>>>
>>> So for that reason I think most people on this thread are saying this is
>>> not a good idea and we should rethink it before make it real.
>>>
>>> just my 2...
>>>
>>> Carlos
>>>
>>>
>>>
>>>
>>> 2018-02-08 18:55 GMT+01:00 Alex Harui <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>:
>>>
>>>> I would much rather we decide on an implementation. It makes
>>>> documentation much easier. I'm all for options, but making fundamental
>>>> things like geometry have options seems like it would make Royale seem
>>>> more complex.
>>>>
>>>> I would not worry about performance until it actually proves to be a
>>>> problem. Clearly, most of our examples do not read x/y/width/height at
>>>> all or very often otherwise we'd have many more layout issues. Most of
>>>> the UI widgets are designed to let the Browser do the layout. So, of
>>>> only
>>>> a small percentage of the UI widgets need x,y,w,h, then it is unlikely
>>>> to
>>>> affect performance.
>>>>
>>>> Also on the JS side we do have the option of overwriting code if we need
>>>> to for folks using transforms and SVG.
>>>>
>>>> People will be porting their Flex apps where they have x,y,width,height
>>>> expectations. Even if it costs a little bit more, it seems like in the
>>>> few places they really need it, it should work like it did in Flex.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 2/8/18, 6:50 AM, "carlos.rovira@gmail.com <ma...@gmail.com> on behalf of Carlos Rovira"
>>>> <carlos.rovira@gmail.com <ma...@gmail.com> on behalf of carlosrovira@apache.org <ma...@apache.org>> wrote:
>>>>
>>>>> Seems more reasonable, since its optional and people wanting it can
>>>>> include...
>>>>>
>>>>> 2018-02-08 14:04 GMT+01:00 Piotr Zarzycki <piotrzarzycki21@gmail.com <ma...@gmail.com>>:
>>>>>
>>>>>> I personally prefer having Bead for such things.
>>>>>>
>>>>>> 2018-02-08 14:01 GMT+01:00 Yishay Weiss <yishayjobs@hotmail.com <ma...@hotmail.com>>:
>>>>>>
>>>>>>> I agree, that’s why I’m proposing to have a bead do the
>>>> calculation.
>>>>>> If
>>>>>>> you care about integrity with actual position on the screen and are
>>>>>> willing
>>>>>>> to sacrifice some performance use ScreenPositionCalculatorBead,
>>>>>> otherwise
>>>>>>> use the default which is more performance oriented.
>>>>>>>
>>>>>>> Another option is to just use a utility function for calculating
>>>> that
>>>>>>> actual screen position when necessary. The util function can get
>>>> the
>>>>>>> element using (component as IRenderedObject).element and then do
>>>>>> whatever
>>>>>>> DOM/flash/wasm queries you need.
>>>>>>>
>>>>>>> From: Carlos Rovira<mailto:carlosrovira@apache.org <ma...@apache.org>>
>>>>>>> Sent: Thursday, February 8, 2018 12:33 PM
>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org><mailto:dev@royale.apache.org <ma...@royale.apache.org>>
>>>>>>> Subject: Re: What is x and y? What is width and height?
>>>>>>>
>>>>>>> I don't have right now a proposal for this, but it seems to me that
>>>>>>> introduce calculations that affects performance will be a bad idea.
>>>>>> That
>>>>>>> will make us not elegible for some escenarios/people. On e of the
>>>>>> things
>>>>>> I
>>>>>>> like from Royale is that in the end we are outputting the most easy
>>>>>> code
>>>>>>> while we are making it easy for coders through MXML/AS3.
>>>>>>> I think we should look the problem in other perspective to avoid
>>>>>> impacts
>>>>>> in
>>>>>>> performance
>>>>>>>
>>>>>>> 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yishayjobs@hotmail.com <ma...@hotmail.com>>:
>>>>>>>
>>>>>>>> How about using beads that implement IPositionCalculator. UIBase
>>>>>> won’t
>>>>>>>> return x and y directly but use a bead to calculate them. The
>>>>>> default
>>>>>>>> SimplePositionCalculatorBead would return x and y based on the
>>>>>> setter
>>>>>>> while
>>>>>>>> the ScreenPositionCalculatorBead would return the values based on
>>>>>> DOM
>>>>>>>> access.
>>>>>>>>
>>>>>>>> From: Gabe Harbs<mailto:harbs.lists@gmail.com <ma...@gmail.com>>
>>>>>>>> Sent: Wednesday, February 7, 2018 6:24 PM
>>>>>>>> To: dev@royale.apache.org <ma...@royale.apache.org><mailto:dev@royale.apache.org <ma...@royale.apache.org>>
>>>>>>>> Subject: Re: What is x and y? What is width and height?
>>>>>>>>
>>>>>>>> FWIW, I do think we need a “constrained layout” which places
>>>>>> *everything*
>>>>>>>> absolutely and does not rely on browser layout. If that layout
>>>> were
>>>>>> to
>>>>>> be
>>>>>>>> used, the bounding box values would be correct.
>>>>>>>>
>>>>>>>>> On Feb 7, 2018, at 6:00 PM, Peter Ent <pent@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I think I agree with Harbs about x,y,width,height just
>>>> returning
>>>>>> the
>>>>>>> set
>>>>>>>>> values if the calculation would be expensive. I wonder what the
>>>>>>>>> circumstances are that we actually need to have precise values
>>>> in
>>>>>>>>> calculations. For example, if I wanted to make a circulate
>>>> layout,
>>>>>> how
>>>>>>>>> would I go about doing that?
>>>>>>>>>
>>>>>>>>> In the places I've done layouts without regard to platform I'm
>>>>>> just
>>>>>>>>> assuming things work. For example, in the DataGridLayout, I
>>>> need
>>>>>> to
>>>>>>>>> transfer the column width given on the js:DataGridColumn
>>>>>> definition
>>>>>> to
>>>>>>>>> both the List (column) and the corresponding Button in the
>>>>>> ButtonBar.
>>>>>>>>> Ideally, the browser takes that (along with display and
>>>> position
>>>>>>> styles)
>>>>>>>>> and just does the right thing with minimum code on our part
>>>>>> (that's
>>>>>> not
>>>>>>>>> actually what I'm doing, so perhaps I should rethink that one
>>>> more
>>>>>>> time).
>>>>>>>>>
>>>>>>>>> ‹peter
>>>>>>>>>
>>>>>>>>> On 2/7/18, 8:35 AM, "Gabe Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>>> The offset values are very expensive.
>>>>>>>>>>
>>>>>>>>>> They are also not completely accurate. I¹ve found it¹s
>>>> difficult
>>>>>> to
>>>>>>> get
>>>>>>>>>> accurate values where SVG and transforms are in play.
>>>>>>>>>>
>>>>>>>>>> I would suggest that x,y,widht and height should reflect *set*
>>>>>> values
>>>>>>>>>> even if they are not always the actual ones.
>>>>>>>>>>
>>>>>>>>>> For cases where it¹s necessary to get accurate measured
>>>> x,y,width
>>>>>> and
>>>>>>>>>> height, I would suggest using ³measured² variations of these
>>>>>> values,
>>>>>>> or
>>>>>>>>>> better, a getMeasuredBounds() method.
>>>>>>>>>>
>>>>>>>>>>> On Feb 7, 2018, at 10:43 AM, Alex Harui
>>>>>> <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> In Royale on JS, we are trying to leverage the browser's
>>>> layout
>>>>>> code
>>>>>>> as
>>>>>>>>>>> much as possible. We only run our own layout code in a few
>>>>>> places.
>>>>>>>>>>> In debugging a few layout issues I discovered that UIBase is
>>>> not
>>>>>>>>>>> reporting
>>>>>>>>>>> x and y the way we expect it from Flex/Flash. Browser
>>>> elements
>>>>>> don't
>>>>>>>>>>> have
>>>>>>>>>>> x and y properties, instead they have offsetLeft and
>>>> offsetTop.
>>>>>>> Mainly
>>>>>>>>>>> for backward-compatibility with Flex/Flash, Royale has had x
>>>>>> and y
>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> API since the beginning. I think it is a bug that x and y do
>>>>>> not
>>>>>> act
>>>>>>>>>>> like
>>>>>>>>>>> they do in Flex and plan to fix that after this release.
>>>>>> Thoughts?
>>>>>>>>>>> I'm a
>>>>>>>>>>> bit concerned of the expense of calculating x and y because
>>>> you
>>>>>> have
>>>>>>> to
>>>>>>>>>>> check if the offsetParent is your immediate parent and get
>>>> the
>>>>>>>>>>> offsetLeft/offsetTop of the immediate parent, but I think
>>>> that's
>>>>>> what
>>>>>>>> it
>>>>>>>>>>> would take to fix it.
>>>>>>>>>>>
>>>>>>>>>>> Similarly (well, sort of), Flex did not support CSS margins,
>>>>>> only
>>>>>>>>>>> padding.
>>>>>>>>>>> The browser reports width (offsetWidth) as factoring in
>>>> content,
>>>>>>>> padding
>>>>>>>>>>> and borders, but not margin. I think that's right, and
>>>> matches
>>>>>> Flex.
>>>>>>>>>>> However, our custom layout algorithms do not currently
>>>> factor in
>>>>>>>> margins
>>>>>>>>>>> since they are not reported in width. I think our custom
>>>> layout
>>>>>>> should
>>>>>>>>>>> request width and margins and do the math. We should not
>>>> change
>>>>>>> width
>>>>>>>>>>> to
>>>>>>>>>>> include margins. Thoughts? This will make our custom layout
>>>>>> code
>>>>>> a
>>>>>>>> bit
>>>>>>>>>>> more expensive as well as it will probably need to call
>>>>>>>>>>> getComputedStyles() on all of the children in order to get
>>>>>> margins.
>>>>>>>>>>> This
>>>>>>>>>>> is also something to fix in the next release.
>>>>>>>>>>>
>>>>>>>>>>> Of course, I could be wrong. Thoughts?
>>>>>>>>>>>
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>> http%3A%2F%2Fabout.me <http://2fabout.me/>%
>>>>>> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>%
>>>> 7C1d1b2927a7234de6a23f08
>>>>>> d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>>>> 7C63653698261760287
>>>>>> 5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Piotr Zarzycki
>>>>>>
>>>>>> Patreon:
>>>>>> *https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>> https%3A%2F%2Fwww.pat
>>>>>> reon.com <http://reon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>
>>>> %7C1d1b2927a723
>>>>>> 4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c3
>>>> 0bf4%7C0%7C0%7C6365369
>>>>>> 82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8
>>>> uMk%2BaMwUG%2BLmY%3D&rese
>>>>>> rved=0
>>>>>>
>>>>>> <https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>> https%3A%2F%2Fwww.pat
>>>>>> reon.com <http://reon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>
>>>> %7C1d1b2927a723
>>>>>> 4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c3
>>>> 0bf4%7C0%7C0%7C6365369
>>>>>> 82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8
>>>> uMk%2BaMwUG%2BLmY%3D&rese
>>>>>> rved=0>*
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>> http%3A%2F%2Fabout.me <http://2fabout.me/>%
>>>>>> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>%
>>>> 7C1d1b2927a7234de6a23f08
>>>>>> d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>>>> 7C63653698261760287
>>>>>> 5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2>
>>> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>%7Cf68e35ff51fb43d848cd08d5
>>> 6f24209a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537123326111877&s
>>> data=1iLsAJVgE1mg2XxRJm3wNR2TM0AemOVXay14wBjbBMI%3D&reserved=0
>
Re: What is x and y? What is width and height?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
In most cases we do output the most basic code. But let's look at one
scenario I expect to run into more than once, which is placing a popup
somewhere.
Like I said, in most of our code, we rarely read back x and y. I don't
even think we read x and y in an absolute positioning container. But I
would imagine there is a fair number of places in existing Flex apps that
do something like:
// center tooltip horizontally
Var tt:FancyToolTip = new FancyToolTip();
...
tt.x = MyWidget.x + MyWidget.width / 2.
This simple example does not work today. I am proposing it should work
for non-transformed UI. I think we can make it work. We can provide
alternative ways of doing it by abstracting the calculation into utility
functions but it just seems strange to me that UI widgets should not have
x,y properties that work like they do in Flex/Flash. But you are right,
we do have the option of not having x,y on our UI widgets.
Another scenario may be as we write more effects. They may have similar
issues picking starting points. I think this might be an issue of how
easy we make it for folks to migrate. The calculation for x and y is just
subtracting the container's offsetLeft or offsetTop from the component's
offsetLeft or offsetTop so one extra read of a property. Of course, I
could be wrong about that.
My 2 cents,
-Alex
On 2/8/18, 10:45 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>in this case it's hard to prove this will be a problem. Maybe the apps
>will
>suffer it very slightly for most people to perceive it, but that's not the
>problem. The problem is our solution will have additional calculations
>*always* that other frameworks doesn't have. And that's goes against our
>principle in JS to output the most basic js code we can since we'll end
>with some strange code only introduced to match a developer time way of
>doing things.
>
>So for that reason I think most people on this thread are saying this is
>not a good idea and we should rethink it before make it real.
>
>just my 2...
>
>Carlos
>
>
>
>
>2018-02-08 18:55 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> I would much rather we decide on an implementation. It makes
>> documentation much easier. I'm all for options, but making fundamental
>> things like geometry have options seems like it would make Royale seem
>> more complex.
>>
>> I would not worry about performance until it actually proves to be a
>> problem. Clearly, most of our examples do not read x/y/width/height at
>> all or very often otherwise we'd have many more layout issues. Most of
>> the UI widgets are designed to let the Browser do the layout. So, of
>>only
>> a small percentage of the UI widgets need x,y,w,h, then it is unlikely
>>to
>> affect performance.
>>
>> Also on the JS side we do have the option of overwriting code if we need
>> to for folks using transforms and SVG.
>>
>> People will be porting their Flex apps where they have x,y,width,height
>> expectations. Even if it costs a little bit more, it seems like in the
>> few places they really need it, it should work like it did in Flex.
>>
>> My 2 cents,
>> -Alex
>>
>> On 2/8/18, 6:50 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Seems more reasonable, since its optional and people wanting it can
>> >include...
>> >
>> >2018-02-08 14:04 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>> >
>> >> I personally prefer having Bead for such things.
>> >>
>> >> 2018-02-08 14:01 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
>> >>
>> >> > I agree, that’s why I’m proposing to have a bead do the
>>calculation.
>> >>If
>> >> > you care about integrity with actual position on the screen and are
>> >> willing
>> >> > to sacrifice some performance use ScreenPositionCalculatorBead,
>> >>otherwise
>> >> > use the default which is more performance oriented.
>> >> >
>> >> > Another option is to just use a utility function for calculating
>>that
>> >> > actual screen position when necessary. The util function can get
>>the
>> >> > element using (component as IRenderedObject).element and then do
>> >>whatever
>> >> > DOM/flash/wasm queries you need.
>> >> >
>> >> > From: Carlos Rovira<ma...@apache.org>
>> >> > Sent: Thursday, February 8, 2018 12:33 PM
>> >> > To: dev@royale.apache.org<ma...@royale.apache.org>
>> >> > Subject: Re: What is x and y? What is width and height?
>> >> >
>> >> > I don't have right now a proposal for this, but it seems to me that
>> >> > introduce calculations that affects performance will be a bad idea.
>> >>That
>> >> > will make us not elegible for some escenarios/people. On e of the
>> >>things
>> >> I
>> >> > like from Royale is that in the end we are outputting the most easy
>> >>code
>> >> > while we are making it easy for coders through MXML/AS3.
>> >> > I think we should look the problem in other perspective to avoid
>> >>impacts
>> >> in
>> >> > performance
>> >> >
>> >> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
>> >> >
>> >> > > How about using beads that implement IPositionCalculator. UIBase
>> >>won’t
>> >> > > return x and y directly but use a bead to calculate them. The
>> >>default
>> >> > > SimplePositionCalculatorBead would return x and y based on the
>> >>setter
>> >> > while
>> >> > > the ScreenPositionCalculatorBead would return the values based on
>> >>DOM
>> >> > > access.
>> >> > >
>> >> > > From: Gabe Harbs<ma...@gmail.com>
>> >> > > Sent: Wednesday, February 7, 2018 6:24 PM
>> >> > > To: dev@royale.apache.org<ma...@royale.apache.org>
>> >> > > Subject: Re: What is x and y? What is width and height?
>> >> > >
>> >> > > FWIW, I do think we need a “constrained layout” which places
>> >> *everything*
>> >> > > absolutely and does not rely on browser layout. If that layout
>>were
>> >>to
>> >> be
>> >> > > used, the bounding box values would be correct.
>> >> > >
>> >> > > > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID>
>> >> wrote:
>> >> > > >
>> >> > > > I think I agree with Harbs about x,y,width,height just
>>returning
>> >>the
>> >> > set
>> >> > > > values if the calculation would be expensive. I wonder what the
>> >> > > > circumstances are that we actually need to have precise values
>>in
>> >> > > > calculations. For example, if I wanted to make a circulate
>>layout,
>> >> how
>> >> > > > would I go about doing that?
>> >> > > >
>> >> > > > In the places I've done layouts without regard to platform I'm
>> >>just
>> >> > > > assuming things work. For example, in the DataGridLayout, I
>>need
>> >>to
>> >> > > > transfer the column width given on the js:DataGridColumn
>> >>definition
>> >> to
>> >> > > > both the List (column) and the corresponding Button in the
>> >>ButtonBar.
>> >> > > > Ideally, the browser takes that (along with display and
>>position
>> >> > styles)
>> >> > > > and just does the right thing with minimum code on our part
>> >>(that's
>> >> not
>> >> > > > actually what I'm doing, so perhaps I should rethink that one
>>more
>> >> > time).
>> >> > > >
>> >> > > > ‹peter
>> >> > > >
>> >> > > > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>> >> > > >
>> >> > > >> The offset values are very expensive.
>> >> > > >>
>> >> > > >> They are also not completely accurate. I¹ve found it¹s
>>difficult
>> >>to
>> >> > get
>> >> > > >> accurate values where SVG and transforms are in play.
>> >> > > >>
>> >> > > >> I would suggest that x,y,widht and height should reflect *set*
>> >> values
>> >> > > >> even if they are not always the actual ones.
>> >> > > >>
>> >> > > >> For cases where it¹s necessary to get accurate measured
>>x,y,width
>> >> and
>> >> > > >> height, I would suggest using ³measured² variations of these
>> >>values,
>> >> > or
>> >> > > >> better, a getMeasuredBounds() method.
>> >> > > >>
>> >> > > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui
>> >><ah...@adobe.com.INVALID>
>> >> > > >>> wrote:
>> >> > > >>>
>> >> > > >>> Hi,
>> >> > > >>>
>> >> > > >>> In Royale on JS, we are trying to leverage the browser's
>>layout
>> >> code
>> >> > as
>> >> > > >>> much as possible. We only run our own layout code in a few
>> >>places.
>> >> > > >>> In debugging a few layout issues I discovered that UIBase is
>>not
>> >> > > >>> reporting
>> >> > > >>> x and y the way we expect it from Flex/Flash. Browser
>>elements
>> >> don't
>> >> > > >>> have
>> >> > > >>> x and y properties, instead they have offsetLeft and
>>offsetTop.
>> >> > Mainly
>> >> > > >>> for backward-compatibility with Flex/Flash, Royale has had x
>> >>and y
>> >> in
>> >> > > >>> the
>> >> > > >>> API since the beginning. I think it is a bug that x and y do
>> >>not
>> >> act
>> >> > > >>> like
>> >> > > >>> they do in Flex and plan to fix that after this release.
>> >>Thoughts?
>> >> > > >>> I'm a
>> >> > > >>> bit concerned of the expense of calculating x and y because
>>you
>> >> have
>> >> > to
>> >> > > >>> check if the offsetParent is your immediate parent and get
>>the
>> >> > > >>> offsetLeft/offsetTop of the immediate parent, but I think
>>that's
>> >> what
>> >> > > it
>> >> > > >>> would take to fix it.
>> >> > > >>>
>> >> > > >>> Similarly (well, sort of), Flex did not support CSS margins,
>> >>only
>> >> > > >>> padding.
>> >> > > >>> The browser reports width (offsetWidth) as factoring in
>>content,
>> >> > > padding
>> >> > > >>> and borders, but not margin. I think that's right, and
>>matches
>> >> Flex.
>> >> > > >>> However, our custom layout algorithms do not currently
>>factor in
>> >> > > margins
>> >> > > >>> since they are not reported in width. I think our custom
>>layout
>> >> > should
>> >> > > >>> request width and margins and do the math. We should not
>>change
>> >> > width
>> >> > > >>> to
>> >> > > >>> include margins. Thoughts? This will make our custom layout
>> >>code
>> >> a
>> >> > > bit
>> >> > > >>> more expensive as well as it will probably need to call
>> >> > > >>> getComputedStyles() on all of the children in order to get
>> >>margins.
>> >> > > >>> This
>> >> > > >>> is also something to fix in the next release.
>> >> > > >>>
>> >> > > >>> Of course, I could be wrong. Thoughts?
>> >> > > >>>
>> >> > > >>> -Alex
>> >> > > >>>
>> >> > > >>
>> >> > > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Carlos Rovira
>> >> >
>> >>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%
>> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C1d1b2927a7234de6a23f08
>> >>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C63653698261760287
>> >>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >>
>> >> Piotr Zarzycki
>> >>
>> >> Patreon:
>> >>*https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7C1d1b2927a723
>> >>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c3
>> 0bf4%7C0%7C0%7C6365369
>> >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8
>> uMk%2BaMwUG%2BLmY%3D&rese
>> >>rved=0
>> >>
>> >><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7C1d1b2927a723
>> >>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c3
>> 0bf4%7C0%7C0%7C6365369
>> >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8
>> uMk%2BaMwUG%2BLmY%3D&rese
>> >>rved=0>*
>> >>
>> >> --
>> >> Carlos Rovira
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%
>> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C1d1b2927a7234de6a23f08
>> >>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C63653698261760287
>> >>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
>> >>
>> >>
>> >>
>>
>>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cf68e35ff51fb43d848cd08d5
>6f24209a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537123326111877&s
>data=1iLsAJVgE1mg2XxRJm3wNR2TM0AemOVXay14wBjbBMI%3D&reserved=0
Re: What is x and y? What is width and height?
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
in this case it's hard to prove this will be a problem. Maybe the apps will
suffer it very slightly for most people to perceive it, but that's not the
problem. The problem is our solution will have additional calculations
*always* that other frameworks doesn't have. And that's goes against our
principle in JS to output the most basic js code we can since we'll end
with some strange code only introduced to match a developer time way of
doing things.
So for that reason I think most people on this thread are saying this is
not a good idea and we should rethink it before make it real.
just my 2...
Carlos
2018-02-08 18:55 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> I would much rather we decide on an implementation. It makes
> documentation much easier. I'm all for options, but making fundamental
> things like geometry have options seems like it would make Royale seem
> more complex.
>
> I would not worry about performance until it actually proves to be a
> problem. Clearly, most of our examples do not read x/y/width/height at
> all or very often otherwise we'd have many more layout issues. Most of
> the UI widgets are designed to let the Browser do the layout. So, of only
> a small percentage of the UI widgets need x,y,w,h, then it is unlikely to
> affect performance.
>
> Also on the JS side we do have the option of overwriting code if we need
> to for folks using transforms and SVG.
>
> People will be porting their Flex apps where they have x,y,width,height
> expectations. Even if it costs a little bit more, it seems like in the
> few places they really need it, it should work like it did in Flex.
>
> My 2 cents,
> -Alex
>
> On 2/8/18, 6:50 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Seems more reasonable, since its optional and people wanting it can
> >include...
> >
> >2018-02-08 14:04 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> >
> >> I personally prefer having Bead for such things.
> >>
> >> 2018-02-08 14:01 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> >>
> >> > I agree, that’s why I’m proposing to have a bead do the calculation.
> >>If
> >> > you care about integrity with actual position on the screen and are
> >> willing
> >> > to sacrifice some performance use ScreenPositionCalculatorBead,
> >>otherwise
> >> > use the default which is more performance oriented.
> >> >
> >> > Another option is to just use a utility function for calculating that
> >> > actual screen position when necessary. The util function can get the
> >> > element using (component as IRenderedObject).element and then do
> >>whatever
> >> > DOM/flash/wasm queries you need.
> >> >
> >> > From: Carlos Rovira<ma...@apache.org>
> >> > Sent: Thursday, February 8, 2018 12:33 PM
> >> > To: dev@royale.apache.org<ma...@royale.apache.org>
> >> > Subject: Re: What is x and y? What is width and height?
> >> >
> >> > I don't have right now a proposal for this, but it seems to me that
> >> > introduce calculations that affects performance will be a bad idea.
> >>That
> >> > will make us not elegible for some escenarios/people. On e of the
> >>things
> >> I
> >> > like from Royale is that in the end we are outputting the most easy
> >>code
> >> > while we are making it easy for coders through MXML/AS3.
> >> > I think we should look the problem in other perspective to avoid
> >>impacts
> >> in
> >> > performance
> >> >
> >> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> >> >
> >> > > How about using beads that implement IPositionCalculator. UIBase
> >>won’t
> >> > > return x and y directly but use a bead to calculate them. The
> >>default
> >> > > SimplePositionCalculatorBead would return x and y based on the
> >>setter
> >> > while
> >> > > the ScreenPositionCalculatorBead would return the values based on
> >>DOM
> >> > > access.
> >> > >
> >> > > From: Gabe Harbs<ma...@gmail.com>
> >> > > Sent: Wednesday, February 7, 2018 6:24 PM
> >> > > To: dev@royale.apache.org<ma...@royale.apache.org>
> >> > > Subject: Re: What is x and y? What is width and height?
> >> > >
> >> > > FWIW, I do think we need a “constrained layout” which places
> >> *everything*
> >> > > absolutely and does not rely on browser layout. If that layout were
> >>to
> >> be
> >> > > used, the bounding box values would be correct.
> >> > >
> >> > > > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID>
> >> wrote:
> >> > > >
> >> > > > I think I agree with Harbs about x,y,width,height just returning
> >>the
> >> > set
> >> > > > values if the calculation would be expensive. I wonder what the
> >> > > > circumstances are that we actually need to have precise values in
> >> > > > calculations. For example, if I wanted to make a circulate layout,
> >> how
> >> > > > would I go about doing that?
> >> > > >
> >> > > > In the places I've done layouts without regard to platform I'm
> >>just
> >> > > > assuming things work. For example, in the DataGridLayout, I need
> >>to
> >> > > > transfer the column width given on the js:DataGridColumn
> >>definition
> >> to
> >> > > > both the List (column) and the corresponding Button in the
> >>ButtonBar.
> >> > > > Ideally, the browser takes that (along with display and position
> >> > styles)
> >> > > > and just does the right thing with minimum code on our part
> >>(that's
> >> not
> >> > > > actually what I'm doing, so perhaps I should rethink that one more
> >> > time).
> >> > > >
> >> > > > ‹peter
> >> > > >
> >> > > > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> >> > > >
> >> > > >> The offset values are very expensive.
> >> > > >>
> >> > > >> They are also not completely accurate. I¹ve found it¹s difficult
> >>to
> >> > get
> >> > > >> accurate values where SVG and transforms are in play.
> >> > > >>
> >> > > >> I would suggest that x,y,widht and height should reflect *set*
> >> values
> >> > > >> even if they are not always the actual ones.
> >> > > >>
> >> > > >> For cases where it¹s necessary to get accurate measured x,y,width
> >> and
> >> > > >> height, I would suggest using ³measured² variations of these
> >>values,
> >> > or
> >> > > >> better, a getMeasuredBounds() method.
> >> > > >>
> >> > > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui
> >><ah...@adobe.com.INVALID>
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>> Hi,
> >> > > >>>
> >> > > >>> In Royale on JS, we are trying to leverage the browser's layout
> >> code
> >> > as
> >> > > >>> much as possible. We only run our own layout code in a few
> >>places.
> >> > > >>> In debugging a few layout issues I discovered that UIBase is not
> >> > > >>> reporting
> >> > > >>> x and y the way we expect it from Flex/Flash. Browser elements
> >> don't
> >> > > >>> have
> >> > > >>> x and y properties, instead they have offsetLeft and offsetTop.
> >> > Mainly
> >> > > >>> for backward-compatibility with Flex/Flash, Royale has had x
> >>and y
> >> in
> >> > > >>> the
> >> > > >>> API since the beginning. I think it is a bug that x and y do
> >>not
> >> act
> >> > > >>> like
> >> > > >>> they do in Flex and plan to fix that after this release.
> >>Thoughts?
> >> > > >>> I'm a
> >> > > >>> bit concerned of the expense of calculating x and y because you
> >> have
> >> > to
> >> > > >>> check if the offsetParent is your immediate parent and get the
> >> > > >>> offsetLeft/offsetTop of the immediate parent, but I think that's
> >> what
> >> > > it
> >> > > >>> would take to fix it.
> >> > > >>>
> >> > > >>> Similarly (well, sort of), Flex did not support CSS margins,
> >>only
> >> > > >>> padding.
> >> > > >>> The browser reports width (offsetWidth) as factoring in content,
> >> > > padding
> >> > > >>> and borders, but not margin. I think that's right, and matches
> >> Flex.
> >> > > >>> However, our custom layout algorithms do not currently factor in
> >> > > margins
> >> > > >>> since they are not reported in width. I think our custom layout
> >> > should
> >> > > >>> request width and margins and do the math. We should not change
> >> > width
> >> > > >>> to
> >> > > >>> include margins. Thoughts? This will make our custom layout
> >>code
> >> a
> >> > > bit
> >> > > >>> more expensive as well as it will probably need to call
> >> > > >>> getComputedStyles() on all of the children in order to get
> >>margins.
> >> > > >>> This
> >> > > >>> is also something to fix in the next release.
> >> > > >>>
> >> > > >>> Of course, I could be wrong. Thoughts?
> >> > > >>>
> >> > > >>> -Alex
> >> > > >>>
> >> > > >>
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C1d1b2927a7234de6a23f08
> >>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C63653698261760287
> >>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
> >> >
> >> >
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon:
> >>*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> %7C1d1b2927a723
> >>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365369
> >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8
> uMk%2BaMwUG%2BLmY%3D&rese
> >>rved=0
> >>
> >><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> %7C1d1b2927a723
> >>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365369
> >>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8
> uMk%2BaMwUG%2BLmY%3D&rese
> >>rved=0>*
> >>
> >> --
> >> Carlos Rovira
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C1d1b2927a7234de6a23f08
> >>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C63653698261760287
> >>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
> >>
> >>
> >>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: What is x and y? What is width and height?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I would much rather we decide on an implementation. It makes
documentation much easier. I'm all for options, but making fundamental
things like geometry have options seems like it would make Royale seem
more complex.
I would not worry about performance until it actually proves to be a
problem. Clearly, most of our examples do not read x/y/width/height at
all or very often otherwise we'd have many more layout issues. Most of
the UI widgets are designed to let the Browser do the layout. So, of only
a small percentage of the UI widgets need x,y,w,h, then it is unlikely to
affect performance.
Also on the JS side we do have the option of overwriting code if we need
to for folks using transforms and SVG.
People will be porting their Flex apps where they have x,y,width,height
expectations. Even if it costs a little bit more, it seems like in the
few places they really need it, it should work like it did in Flex.
My 2 cents,
-Alex
On 2/8/18, 6:50 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Seems more reasonable, since its optional and people wanting it can
>include...
>
>2018-02-08 14:04 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>
>> I personally prefer having Bead for such things.
>>
>> 2018-02-08 14:01 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
>>
>> > I agree, that’s why I’m proposing to have a bead do the calculation.
>>If
>> > you care about integrity with actual position on the screen and are
>> willing
>> > to sacrifice some performance use ScreenPositionCalculatorBead,
>>otherwise
>> > use the default which is more performance oriented.
>> >
>> > Another option is to just use a utility function for calculating that
>> > actual screen position when necessary. The util function can get the
>> > element using (component as IRenderedObject).element and then do
>>whatever
>> > DOM/flash/wasm queries you need.
>> >
>> > From: Carlos Rovira<ma...@apache.org>
>> > Sent: Thursday, February 8, 2018 12:33 PM
>> > To: dev@royale.apache.org<ma...@royale.apache.org>
>> > Subject: Re: What is x and y? What is width and height?
>> >
>> > I don't have right now a proposal for this, but it seems to me that
>> > introduce calculations that affects performance will be a bad idea.
>>That
>> > will make us not elegible for some escenarios/people. On e of the
>>things
>> I
>> > like from Royale is that in the end we are outputting the most easy
>>code
>> > while we are making it easy for coders through MXML/AS3.
>> > I think we should look the problem in other perspective to avoid
>>impacts
>> in
>> > performance
>> >
>> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
>> >
>> > > How about using beads that implement IPositionCalculator. UIBase
>>won’t
>> > > return x and y directly but use a bead to calculate them. The
>>default
>> > > SimplePositionCalculatorBead would return x and y based on the
>>setter
>> > while
>> > > the ScreenPositionCalculatorBead would return the values based on
>>DOM
>> > > access.
>> > >
>> > > From: Gabe Harbs<ma...@gmail.com>
>> > > Sent: Wednesday, February 7, 2018 6:24 PM
>> > > To: dev@royale.apache.org<ma...@royale.apache.org>
>> > > Subject: Re: What is x and y? What is width and height?
>> > >
>> > > FWIW, I do think we need a “constrained layout” which places
>> *everything*
>> > > absolutely and does not rely on browser layout. If that layout were
>>to
>> be
>> > > used, the bounding box values would be correct.
>> > >
>> > > > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID>
>> wrote:
>> > > >
>> > > > I think I agree with Harbs about x,y,width,height just returning
>>the
>> > set
>> > > > values if the calculation would be expensive. I wonder what the
>> > > > circumstances are that we actually need to have precise values in
>> > > > calculations. For example, if I wanted to make a circulate layout,
>> how
>> > > > would I go about doing that?
>> > > >
>> > > > In the places I've done layouts without regard to platform I'm
>>just
>> > > > assuming things work. For example, in the DataGridLayout, I need
>>to
>> > > > transfer the column width given on the js:DataGridColumn
>>definition
>> to
>> > > > both the List (column) and the corresponding Button in the
>>ButtonBar.
>> > > > Ideally, the browser takes that (along with display and position
>> > styles)
>> > > > and just does the right thing with minimum code on our part
>>(that's
>> not
>> > > > actually what I'm doing, so perhaps I should rethink that one more
>> > time).
>> > > >
>> > > > ‹peter
>> > > >
>> > > > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>> > > >
>> > > >> The offset values are very expensive.
>> > > >>
>> > > >> They are also not completely accurate. I¹ve found it¹s difficult
>>to
>> > get
>> > > >> accurate values where SVG and transforms are in play.
>> > > >>
>> > > >> I would suggest that x,y,widht and height should reflect *set*
>> values
>> > > >> even if they are not always the actual ones.
>> > > >>
>> > > >> For cases where it¹s necessary to get accurate measured x,y,width
>> and
>> > > >> height, I would suggest using ³measured² variations of these
>>values,
>> > or
>> > > >> better, a getMeasuredBounds() method.
>> > > >>
>> > > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui
>><ah...@adobe.com.INVALID>
>> > > >>> wrote:
>> > > >>>
>> > > >>> Hi,
>> > > >>>
>> > > >>> In Royale on JS, we are trying to leverage the browser's layout
>> code
>> > as
>> > > >>> much as possible. We only run our own layout code in a few
>>places.
>> > > >>> In debugging a few layout issues I discovered that UIBase is not
>> > > >>> reporting
>> > > >>> x and y the way we expect it from Flex/Flash. Browser elements
>> don't
>> > > >>> have
>> > > >>> x and y properties, instead they have offsetLeft and offsetTop.
>> > Mainly
>> > > >>> for backward-compatibility with Flex/Flash, Royale has had x
>>and y
>> in
>> > > >>> the
>> > > >>> API since the beginning. I think it is a bug that x and y do
>>not
>> act
>> > > >>> like
>> > > >>> they do in Flex and plan to fix that after this release.
>>Thoughts?
>> > > >>> I'm a
>> > > >>> bit concerned of the expense of calculating x and y because you
>> have
>> > to
>> > > >>> check if the offsetParent is your immediate parent and get the
>> > > >>> offsetLeft/offsetTop of the immediate parent, but I think that's
>> what
>> > > it
>> > > >>> would take to fix it.
>> > > >>>
>> > > >>> Similarly (well, sort of), Flex did not support CSS margins,
>>only
>> > > >>> padding.
>> > > >>> The browser reports width (offsetWidth) as factoring in content,
>> > > padding
>> > > >>> and borders, but not margin. I think that's right, and matches
>> Flex.
>> > > >>> However, our custom layout algorithms do not currently factor in
>> > > margins
>> > > >>> since they are not reported in width. I think our custom layout
>> > should
>> > > >>> request width and margins and do the math. We should not change
>> > width
>> > > >>> to
>> > > >>> include margins. Thoughts? This will make our custom layout
>>code
>> a
>> > > bit
>> > > >>> more expensive as well as it will probably need to call
>> > > >>> getComputedStyles() on all of the children in order to get
>>margins.
>> > > >>> This
>> > > >>> is also something to fix in the next release.
>> > > >>>
>> > > >>> Of course, I could be wrong. Thoughts?
>> > > >>>
>> > > >>> -Alex
>> > > >>>
>> > > >>
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Carlos Rovira
>> >
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a7234de6a23f08
>>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653698261760287
>>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
>> >
>> >
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon:
>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a723
>>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365369
>>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8uMk%2BaMwUG%2BLmY%3D&rese
>>rved=0
>>
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a723
>>4de6a23f08d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365369
>>82617602875&sdata=WZgLyBXlWjrYwjHjlPg1zomO42zmd8uMk%2BaMwUG%2BLmY%3D&rese
>>rved=0>*
>>
>> --
>> Carlos Rovira
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1d1b2927a7234de6a23f08
>>d56f035e31%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653698261760287
>>5&sdata=3poyGxcDReAGgaaGUjqYtXU5Hzk8VQpWw1HF0MfsuuA%3D&reserved=0
>>
>>
>>
Re: What is x and y? What is width and height?
Posted by Carlos Rovira <ca...@apache.org>.
Seems more reasonable, since its optional and people wanting it can
include...
2018-02-08 14:04 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> I personally prefer having Bead for such things.
>
> 2018-02-08 14:01 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
>
> > I agree, that’s why I’m proposing to have a bead do the calculation. If
> > you care about integrity with actual position on the screen and are
> willing
> > to sacrifice some performance use ScreenPositionCalculatorBead, otherwise
> > use the default which is more performance oriented.
> >
> > Another option is to just use a utility function for calculating that
> > actual screen position when necessary. The util function can get the
> > element using (component as IRenderedObject).element and then do whatever
> > DOM/flash/wasm queries you need.
> >
> > From: Carlos Rovira<ma...@apache.org>
> > Sent: Thursday, February 8, 2018 12:33 PM
> > To: dev@royale.apache.org<ma...@royale.apache.org>
> > Subject: Re: What is x and y? What is width and height?
> >
> > I don't have right now a proposal for this, but it seems to me that
> > introduce calculations that affects performance will be a bad idea. That
> > will make us not elegible for some escenarios/people. On e of the things
> I
> > like from Royale is that in the end we are outputting the most easy code
> > while we are making it easy for coders through MXML/AS3.
> > I think we should look the problem in other perspective to avoid impacts
> in
> > performance
> >
> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> >
> > > How about using beads that implement IPositionCalculator. UIBase won’t
> > > return x and y directly but use a bead to calculate them. The default
> > > SimplePositionCalculatorBead would return x and y based on the setter
> > while
> > > the ScreenPositionCalculatorBead would return the values based on DOM
> > > access.
> > >
> > > From: Gabe Harbs<ma...@gmail.com>
> > > Sent: Wednesday, February 7, 2018 6:24 PM
> > > To: dev@royale.apache.org<ma...@royale.apache.org>
> > > Subject: Re: What is x and y? What is width and height?
> > >
> > > FWIW, I do think we need a “constrained layout” which places
> *everything*
> > > absolutely and does not rely on browser layout. If that layout were to
> be
> > > used, the bounding box values would be correct.
> > >
> > > > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID>
> wrote:
> > > >
> > > > I think I agree with Harbs about x,y,width,height just returning the
> > set
> > > > values if the calculation would be expensive. I wonder what the
> > > > circumstances are that we actually need to have precise values in
> > > > calculations. For example, if I wanted to make a circulate layout,
> how
> > > > would I go about doing that?
> > > >
> > > > In the places I've done layouts without regard to platform I'm just
> > > > assuming things work. For example, in the DataGridLayout, I need to
> > > > transfer the column width given on the js:DataGridColumn definition
> to
> > > > both the List (column) and the corresponding Button in the ButtonBar.
> > > > Ideally, the browser takes that (along with display and position
> > styles)
> > > > and just does the right thing with minimum code on our part (that's
> not
> > > > actually what I'm doing, so perhaps I should rethink that one more
> > time).
> > > >
> > > > ‹peter
> > > >
> > > > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> > > >
> > > >> The offset values are very expensive.
> > > >>
> > > >> They are also not completely accurate. I¹ve found it¹s difficult to
> > get
> > > >> accurate values where SVG and transforms are in play.
> > > >>
> > > >> I would suggest that x,y,widht and height should reflect *set*
> values
> > > >> even if they are not always the actual ones.
> > > >>
> > > >> For cases where it¹s necessary to get accurate measured x,y,width
> and
> > > >> height, I would suggest using ³measured² variations of these values,
> > or
> > > >> better, a getMeasuredBounds() method.
> > > >>
> > > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> > > >>> wrote:
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> In Royale on JS, we are trying to leverage the browser's layout
> code
> > as
> > > >>> much as possible. We only run our own layout code in a few places.
> > > >>> In debugging a few layout issues I discovered that UIBase is not
> > > >>> reporting
> > > >>> x and y the way we expect it from Flex/Flash. Browser elements
> don't
> > > >>> have
> > > >>> x and y properties, instead they have offsetLeft and offsetTop.
> > Mainly
> > > >>> for backward-compatibility with Flex/Flash, Royale has had x and y
> in
> > > >>> the
> > > >>> API since the beginning. I think it is a bug that x and y do not
> act
> > > >>> like
> > > >>> they do in Flex and plan to fix that after this release. Thoughts?
> > > >>> I'm a
> > > >>> bit concerned of the expense of calculating x and y because you
> have
> > to
> > > >>> check if the offsetParent is your immediate parent and get the
> > > >>> offsetLeft/offsetTop of the immediate parent, but I think that's
> what
> > > it
> > > >>> would take to fix it.
> > > >>>
> > > >>> Similarly (well, sort of), Flex did not support CSS margins, only
> > > >>> padding.
> > > >>> The browser reports width (offsetWidth) as factoring in content,
> > > padding
> > > >>> and borders, but not margin. I think that's right, and matches
> Flex.
> > > >>> However, our custom layout algorithms do not currently factor in
> > > margins
> > > >>> since they are not reported in width. I think our custom layout
> > should
> > > >>> request width and margins and do the math. We should not change
> > width
> > > >>> to
> > > >>> include margins. Thoughts? This will make our custom layout code
> a
> > > bit
> > > >>> more expensive as well as it will probably need to call
> > > >>> getComputedStyles() on all of the children in order to get margins.
> > > >>> This
> > > >>> is also something to fix in the next release.
> > > >>>
> > > >>> Of course, I could be wrong. Thoughts?
> > > >>>
> > > >>> -Alex
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
Re: What is x and y? What is width and height?
Posted by Piotr Zarzycki <pi...@gmail.com>.
I personally prefer having Bead for such things.
2018-02-08 14:01 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> I agree, that’s why I’m proposing to have a bead do the calculation. If
> you care about integrity with actual position on the screen and are willing
> to sacrifice some performance use ScreenPositionCalculatorBead, otherwise
> use the default which is more performance oriented.
>
> Another option is to just use a utility function for calculating that
> actual screen position when necessary. The util function can get the
> element using (component as IRenderedObject).element and then do whatever
> DOM/flash/wasm queries you need.
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Thursday, February 8, 2018 12:33 PM
> To: dev@royale.apache.org<ma...@royale.apache.org>
> Subject: Re: What is x and y? What is width and height?
>
> I don't have right now a proposal for this, but it seems to me that
> introduce calculations that affects performance will be a bad idea. That
> will make us not elegible for some escenarios/people. On e of the things I
> like from Royale is that in the end we are outputting the most easy code
> while we are making it easy for coders through MXML/AS3.
> I think we should look the problem in other perspective to avoid impacts in
> performance
>
> 2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
>
> > How about using beads that implement IPositionCalculator. UIBase won’t
> > return x and y directly but use a bead to calculate them. The default
> > SimplePositionCalculatorBead would return x and y based on the setter
> while
> > the ScreenPositionCalculatorBead would return the values based on DOM
> > access.
> >
> > From: Gabe Harbs<ma...@gmail.com>
> > Sent: Wednesday, February 7, 2018 6:24 PM
> > To: dev@royale.apache.org<ma...@royale.apache.org>
> > Subject: Re: What is x and y? What is width and height?
> >
> > FWIW, I do think we need a “constrained layout” which places *everything*
> > absolutely and does not rely on browser layout. If that layout were to be
> > used, the bounding box values would be correct.
> >
> > > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
> > >
> > > I think I agree with Harbs about x,y,width,height just returning the
> set
> > > values if the calculation would be expensive. I wonder what the
> > > circumstances are that we actually need to have precise values in
> > > calculations. For example, if I wanted to make a circulate layout, how
> > > would I go about doing that?
> > >
> > > In the places I've done layouts without regard to platform I'm just
> > > assuming things work. For example, in the DataGridLayout, I need to
> > > transfer the column width given on the js:DataGridColumn definition to
> > > both the List (column) and the corresponding Button in the ButtonBar.
> > > Ideally, the browser takes that (along with display and position
> styles)
> > > and just does the right thing with minimum code on our part (that's not
> > > actually what I'm doing, so perhaps I should rethink that one more
> time).
> > >
> > > ‹peter
> > >
> > > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> > >
> > >> The offset values are very expensive.
> > >>
> > >> They are also not completely accurate. I¹ve found it¹s difficult to
> get
> > >> accurate values where SVG and transforms are in play.
> > >>
> > >> I would suggest that x,y,widht and height should reflect *set* values
> > >> even if they are not always the actual ones.
> > >>
> > >> For cases where it¹s necessary to get accurate measured x,y,width and
> > >> height, I would suggest using ³measured² variations of these values,
> or
> > >> better, a getMeasuredBounds() method.
> > >>
> > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> > >>> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> In Royale on JS, we are trying to leverage the browser's layout code
> as
> > >>> much as possible. We only run our own layout code in a few places.
> > >>> In debugging a few layout issues I discovered that UIBase is not
> > >>> reporting
> > >>> x and y the way we expect it from Flex/Flash. Browser elements don't
> > >>> have
> > >>> x and y properties, instead they have offsetLeft and offsetTop.
> Mainly
> > >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> > >>> the
> > >>> API since the beginning. I think it is a bug that x and y do not act
> > >>> like
> > >>> they do in Flex and plan to fix that after this release. Thoughts?
> > >>> I'm a
> > >>> bit concerned of the expense of calculating x and y because you have
> to
> > >>> check if the offsetParent is your immediate parent and get the
> > >>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> > it
> > >>> would take to fix it.
> > >>>
> > >>> Similarly (well, sort of), Flex did not support CSS margins, only
> > >>> padding.
> > >>> The browser reports width (offsetWidth) as factoring in content,
> > padding
> > >>> and borders, but not margin. I think that's right, and matches Flex.
> > >>> However, our custom layout algorithms do not currently factor in
> > margins
> > >>> since they are not reported in width. I think our custom layout
> should
> > >>> request width and margins and do the math. We should not change
> width
> > >>> to
> > >>> include margins. Thoughts? This will make our custom layout code a
> > bit
> > >>> more expensive as well as it will probably need to call
> > >>> getComputedStyles() on all of the children in order to get margins.
> > >>> This
> > >>> is also something to fix in the next release.
> > >>>
> > >>> Of course, I could be wrong. Thoughts?
> > >>>
> > >>> -Alex
> > >>>
> > >>
> > >
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
RE: What is x and y? What is width and height?
Posted by Yishay Weiss <yi...@hotmail.com>.
I agree, that’s why I’m proposing to have a bead do the calculation. If you care about integrity with actual position on the screen and are willing to sacrifice some performance use ScreenPositionCalculatorBead, otherwise use the default which is more performance oriented.
Another option is to just use a utility function for calculating that actual screen position when necessary. The util function can get the element using (component as IRenderedObject).element and then do whatever DOM/flash/wasm queries you need.
From: Carlos Rovira<ma...@apache.org>
Sent: Thursday, February 8, 2018 12:33 PM
To: dev@royale.apache.org<ma...@royale.apache.org>
Subject: Re: What is x and y? What is width and height?
I don't have right now a proposal for this, but it seems to me that
introduce calculations that affects performance will be a bad idea. That
will make us not elegible for some escenarios/people. On e of the things I
like from Royale is that in the end we are outputting the most easy code
while we are making it easy for coders through MXML/AS3.
I think we should look the problem in other perspective to avoid impacts in
performance
2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> How about using beads that implement IPositionCalculator. UIBase won’t
> return x and y directly but use a bead to calculate them. The default
> SimplePositionCalculatorBead would return x and y based on the setter while
> the ScreenPositionCalculatorBead would return the values based on DOM
> access.
>
> From: Gabe Harbs<ma...@gmail.com>
> Sent: Wednesday, February 7, 2018 6:24 PM
> To: dev@royale.apache.org<ma...@royale.apache.org>
> Subject: Re: What is x and y? What is width and height?
>
> FWIW, I do think we need a “constrained layout” which places *everything*
> absolutely and does not rely on browser layout. If that layout were to be
> used, the bounding box values would be correct.
>
> > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
> >
> > I think I agree with Harbs about x,y,width,height just returning the set
> > values if the calculation would be expensive. I wonder what the
> > circumstances are that we actually need to have precise values in
> > calculations. For example, if I wanted to make a circulate layout, how
> > would I go about doing that?
> >
> > In the places I've done layouts without regard to platform I'm just
> > assuming things work. For example, in the DataGridLayout, I need to
> > transfer the column width given on the js:DataGridColumn definition to
> > both the List (column) and the corresponding Button in the ButtonBar.
> > Ideally, the browser takes that (along with display and position styles)
> > and just does the right thing with minimum code on our part (that's not
> > actually what I'm doing, so perhaps I should rethink that one more time).
> >
> > ‹peter
> >
> > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> >
> >> The offset values are very expensive.
> >>
> >> They are also not completely accurate. I¹ve found it¹s difficult to get
> >> accurate values where SVG and transforms are in play.
> >>
> >> I would suggest that x,y,widht and height should reflect *set* values
> >> even if they are not always the actual ones.
> >>
> >> For cases where it¹s necessary to get accurate measured x,y,width and
> >> height, I would suggest using ³measured² variations of these values, or
> >> better, a getMeasuredBounds() method.
> >>
> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In Royale on JS, we are trying to leverage the browser's layout code as
> >>> much as possible. We only run our own layout code in a few places.
> >>> In debugging a few layout issues I discovered that UIBase is not
> >>> reporting
> >>> x and y the way we expect it from Flex/Flash. Browser elements don't
> >>> have
> >>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
> >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>> the
> >>> API since the beginning. I think it is a bug that x and y do not act
> >>> like
> >>> they do in Flex and plan to fix that after this release. Thoughts?
> >>> I'm a
> >>> bit concerned of the expense of calculating x and y because you have to
> >>> check if the offsetParent is your immediate parent and get the
> >>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> it
> >>> would take to fix it.
> >>>
> >>> Similarly (well, sort of), Flex did not support CSS margins, only
> >>> padding.
> >>> The browser reports width (offsetWidth) as factoring in content,
> padding
> >>> and borders, but not margin. I think that's right, and matches Flex.
> >>> However, our custom layout algorithms do not currently factor in
> margins
> >>> since they are not reported in width. I think our custom layout should
> >>> request width and margins and do the math. We should not change width
> >>> to
> >>> include margins. Thoughts? This will make our custom layout code a
> bit
> >>> more expensive as well as it will probably need to call
> >>> getComputedStyles() on all of the children in order to get margins.
> >>> This
> >>> is also something to fix in the next release.
> >>>
> >>> Of course, I could be wrong. Thoughts?
> >>>
> >>> -Alex
> >>>
> >>
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: What is x and y? What is width and height?
Posted by Carlos Rovira <ca...@apache.org>.
I don't have right now a proposal for this, but it seems to me that
introduce calculations that affects performance will be a bad idea. That
will make us not elegible for some escenarios/people. On e of the things I
like from Royale is that in the end we are outputting the most easy code
while we are making it easy for coders through MXML/AS3.
I think we should look the problem in other perspective to avoid impacts in
performance
2018-02-08 7:26 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> How about using beads that implement IPositionCalculator. UIBase won’t
> return x and y directly but use a bead to calculate them. The default
> SimplePositionCalculatorBead would return x and y based on the setter while
> the ScreenPositionCalculatorBead would return the values based on DOM
> access.
>
> From: Gabe Harbs<ma...@gmail.com>
> Sent: Wednesday, February 7, 2018 6:24 PM
> To: dev@royale.apache.org<ma...@royale.apache.org>
> Subject: Re: What is x and y? What is width and height?
>
> FWIW, I do think we need a “constrained layout” which places *everything*
> absolutely and does not rely on browser layout. If that layout were to be
> used, the bounding box values would be correct.
>
> > On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
> >
> > I think I agree with Harbs about x,y,width,height just returning the set
> > values if the calculation would be expensive. I wonder what the
> > circumstances are that we actually need to have precise values in
> > calculations. For example, if I wanted to make a circulate layout, how
> > would I go about doing that?
> >
> > In the places I've done layouts without regard to platform I'm just
> > assuming things work. For example, in the DataGridLayout, I need to
> > transfer the column width given on the js:DataGridColumn definition to
> > both the List (column) and the corresponding Button in the ButtonBar.
> > Ideally, the browser takes that (along with display and position styles)
> > and just does the right thing with minimum code on our part (that's not
> > actually what I'm doing, so perhaps I should rethink that one more time).
> >
> > ‹peter
> >
> > On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> >
> >> The offset values are very expensive.
> >>
> >> They are also not completely accurate. I¹ve found it¹s difficult to get
> >> accurate values where SVG and transforms are in play.
> >>
> >> I would suggest that x,y,widht and height should reflect *set* values
> >> even if they are not always the actual ones.
> >>
> >> For cases where it¹s necessary to get accurate measured x,y,width and
> >> height, I would suggest using ³measured² variations of these values, or
> >> better, a getMeasuredBounds() method.
> >>
> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In Royale on JS, we are trying to leverage the browser's layout code as
> >>> much as possible. We only run our own layout code in a few places.
> >>> In debugging a few layout issues I discovered that UIBase is not
> >>> reporting
> >>> x and y the way we expect it from Flex/Flash. Browser elements don't
> >>> have
> >>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
> >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>> the
> >>> API since the beginning. I think it is a bug that x and y do not act
> >>> like
> >>> they do in Flex and plan to fix that after this release. Thoughts?
> >>> I'm a
> >>> bit concerned of the expense of calculating x and y because you have to
> >>> check if the offsetParent is your immediate parent and get the
> >>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> it
> >>> would take to fix it.
> >>>
> >>> Similarly (well, sort of), Flex did not support CSS margins, only
> >>> padding.
> >>> The browser reports width (offsetWidth) as factoring in content,
> padding
> >>> and borders, but not margin. I think that's right, and matches Flex.
> >>> However, our custom layout algorithms do not currently factor in
> margins
> >>> since they are not reported in width. I think our custom layout should
> >>> request width and margins and do the math. We should not change width
> >>> to
> >>> include margins. Thoughts? This will make our custom layout code a
> bit
> >>> more expensive as well as it will probably need to call
> >>> getComputedStyles() on all of the children in order to get margins.
> >>> This
> >>> is also something to fix in the next release.
> >>>
> >>> Of course, I could be wrong. Thoughts?
> >>>
> >>> -Alex
> >>>
> >>
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
RE: What is x and y? What is width and height?
Posted by Yishay Weiss <yi...@hotmail.com>.
How about using beads that implement IPositionCalculator. UIBase won’t return x and y directly but use a bead to calculate them. The default SimplePositionCalculatorBead would return x and y based on the setter while the ScreenPositionCalculatorBead would return the values based on DOM access.
From: Gabe Harbs<ma...@gmail.com>
Sent: Wednesday, February 7, 2018 6:24 PM
To: dev@royale.apache.org<ma...@royale.apache.org>
Subject: Re: What is x and y? What is width and height?
FWIW, I do think we need a “constrained layout” which places *everything* absolutely and does not rely on browser layout. If that layout were to be used, the bounding box values would be correct.
> On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>
> I think I agree with Harbs about x,y,width,height just returning the set
> values if the calculation would be expensive. I wonder what the
> circumstances are that we actually need to have precise values in
> calculations. For example, if I wanted to make a circulate layout, how
> would I go about doing that?
>
> In the places I've done layouts without regard to platform I'm just
> assuming things work. For example, in the DataGridLayout, I need to
> transfer the column width given on the js:DataGridColumn definition to
> both the List (column) and the corresponding Button in the ButtonBar.
> Ideally, the browser takes that (along with display and position styles)
> and just does the right thing with minimum code on our part (that's not
> actually what I'm doing, so perhaps I should rethink that one more time).
>
> ‹peter
>
> On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>
>> The offset values are very expensive.
>>
>> They are also not completely accurate. I¹ve found it¹s difficult to get
>> accurate values where SVG and transforms are in play.
>>
>> I would suggest that x,y,widht and height should reflect *set* values
>> even if they are not always the actual ones.
>>
>> For cases where it¹s necessary to get accurate measured x,y,width and
>> height, I would suggest using ³measured² variations of these values, or
>> better, a getMeasuredBounds() method.
>>
>>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Hi,
>>>
>>> In Royale on JS, we are trying to leverage the browser's layout code as
>>> much as possible. We only run our own layout code in a few places.
>>> In debugging a few layout issues I discovered that UIBase is not
>>> reporting
>>> x and y the way we expect it from Flex/Flash. Browser elements don't
>>> have
>>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
>>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>> the
>>> API since the beginning. I think it is a bug that x and y do not act
>>> like
>>> they do in Flex and plan to fix that after this release. Thoughts?
>>> I'm a
>>> bit concerned of the expense of calculating x and y because you have to
>>> check if the offsetParent is your immediate parent and get the
>>> offsetLeft/offsetTop of the immediate parent, but I think that's what it
>>> would take to fix it.
>>>
>>> Similarly (well, sort of), Flex did not support CSS margins, only
>>> padding.
>>> The browser reports width (offsetWidth) as factoring in content, padding
>>> and borders, but not margin. I think that's right, and matches Flex.
>>> However, our custom layout algorithms do not currently factor in margins
>>> since they are not reported in width. I think our custom layout should
>>> request width and margins and do the math. We should not change width
>>> to
>>> include margins. Thoughts? This will make our custom layout code a bit
>>> more expensive as well as it will probably need to call
>>> getComputedStyles() on all of the children in order to get margins.
>>> This
>>> is also something to fix in the next release.
>>>
>>> Of course, I could be wrong. Thoughts?
>>>
>>> -Alex
>>>
>>
>
Re: What is x and y? What is width and height?
Posted by Gabe Harbs <ha...@gmail.com>.
FWIW, I do think we need a “constrained layout” which places *everything* absolutely and does not rely on browser layout. If that layout were to be used, the bounding box values would be correct.
> On Feb 7, 2018, at 6:00 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>
> I think I agree with Harbs about x,y,width,height just returning the set
> values if the calculation would be expensive. I wonder what the
> circumstances are that we actually need to have precise values in
> calculations. For example, if I wanted to make a circulate layout, how
> would I go about doing that?
>
> In the places I've done layouts without regard to platform I'm just
> assuming things work. For example, in the DataGridLayout, I need to
> transfer the column width given on the js:DataGridColumn definition to
> both the List (column) and the corresponding Button in the ButtonBar.
> Ideally, the browser takes that (along with display and position styles)
> and just does the right thing with minimum code on our part (that's not
> actually what I'm doing, so perhaps I should rethink that one more time).
>
> ‹peter
>
> On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>
>> The offset values are very expensive.
>>
>> They are also not completely accurate. I¹ve found it¹s difficult to get
>> accurate values where SVG and transforms are in play.
>>
>> I would suggest that x,y,widht and height should reflect *set* values
>> even if they are not always the actual ones.
>>
>> For cases where it¹s necessary to get accurate measured x,y,width and
>> height, I would suggest using ³measured² variations of these values, or
>> better, a getMeasuredBounds() method.
>>
>>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Hi,
>>>
>>> In Royale on JS, we are trying to leverage the browser's layout code as
>>> much as possible. We only run our own layout code in a few places.
>>> In debugging a few layout issues I discovered that UIBase is not
>>> reporting
>>> x and y the way we expect it from Flex/Flash. Browser elements don't
>>> have
>>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
>>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>> the
>>> API since the beginning. I think it is a bug that x and y do not act
>>> like
>>> they do in Flex and plan to fix that after this release. Thoughts?
>>> I'm a
>>> bit concerned of the expense of calculating x and y because you have to
>>> check if the offsetParent is your immediate parent and get the
>>> offsetLeft/offsetTop of the immediate parent, but I think that's what it
>>> would take to fix it.
>>>
>>> Similarly (well, sort of), Flex did not support CSS margins, only
>>> padding.
>>> The browser reports width (offsetWidth) as factoring in content, padding
>>> and borders, but not margin. I think that's right, and matches Flex.
>>> However, our custom layout algorithms do not currently factor in margins
>>> since they are not reported in width. I think our custom layout should
>>> request width and margins and do the math. We should not change width
>>> to
>>> include margins. Thoughts? This will make our custom layout code a bit
>>> more expensive as well as it will probably need to call
>>> getComputedStyles() on all of the children in order to get margins.
>>> This
>>> is also something to fix in the next release.
>>>
>>> Of course, I could be wrong. Thoughts?
>>>
>>> -Alex
>>>
>>
>
Re: What is x and y? What is width and height?
Posted by Peter Ent <pe...@adobe.com.INVALID>.
I think I agree with Harbs about x,y,width,height just returning the set
values if the calculation would be expensive. I wonder what the
circumstances are that we actually need to have precise values in
calculations. For example, if I wanted to make a circulate layout, how
would I go about doing that?
In the places I've done layouts without regard to platform I'm just
assuming things work. For example, in the DataGridLayout, I need to
transfer the column width given on the js:DataGridColumn definition to
both the List (column) and the corresponding Button in the ButtonBar.
Ideally, the browser takes that (along with display and position styles)
and just does the right thing with minimum code on our part (that's not
actually what I'm doing, so perhaps I should rethink that one more time).
‹peter
On 2/7/18, 8:35 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>The offset values are very expensive.
>
>They are also not completely accurate. I¹ve found it¹s difficult to get
>accurate values where SVG and transforms are in play.
>
>I would suggest that x,y,widht and height should reflect *set* values
>even if they are not always the actual ones.
>
>For cases where it¹s necessary to get accurate measured x,y,width and
>height, I would suggest using ³measured² variations of these values, or
>better, a getMeasuredBounds() method.
>
>> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> Hi,
>>
>> In Royale on JS, we are trying to leverage the browser's layout code as
>> much as possible. We only run our own layout code in a few places.
>> In debugging a few layout issues I discovered that UIBase is not
>>reporting
>> x and y the way we expect it from Flex/Flash. Browser elements don't
>>have
>> x and y properties, instead they have offsetLeft and offsetTop. Mainly
>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>the
>> API since the beginning. I think it is a bug that x and y do not act
>>like
>> they do in Flex and plan to fix that after this release. Thoughts?
>>I'm a
>> bit concerned of the expense of calculating x and y because you have to
>> check if the offsetParent is your immediate parent and get the
>> offsetLeft/offsetTop of the immediate parent, but I think that's what it
>> would take to fix it.
>>
>> Similarly (well, sort of), Flex did not support CSS margins, only
>>padding.
>> The browser reports width (offsetWidth) as factoring in content, padding
>> and borders, but not margin. I think that's right, and matches Flex.
>> However, our custom layout algorithms do not currently factor in margins
>> since they are not reported in width. I think our custom layout should
>> request width and margins and do the math. We should not change width
>>to
>> include margins. Thoughts? This will make our custom layout code a bit
>> more expensive as well as it will probably need to call
>> getComputedStyles() on all of the children in order to get margins.
>>This
>> is also something to fix in the next release.
>>
>> Of course, I could be wrong. Thoughts?
>>
>> -Alex
>>
>
Re: What is x and y? What is width and height?
Posted by Gabe Harbs <ha...@gmail.com>.
The offset values are very expensive.
They are also not completely accurate. I’ve found it’s difficult to get accurate values where SVG and transforms are in play.
I would suggest that x,y,widht and height should reflect *set* values even if they are not always the actual ones.
For cases where it’s necessary to get accurate measured x,y,width and height, I would suggest using “measured” variations of these values, or better, a getMeasuredBounds() method.
> On Feb 7, 2018, at 10:43 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Hi,
>
> In Royale on JS, we are trying to leverage the browser's layout code as
> much as possible. We only run our own layout code in a few places.
> In debugging a few layout issues I discovered that UIBase is not reporting
> x and y the way we expect it from Flex/Flash. Browser elements don't have
> x and y properties, instead they have offsetLeft and offsetTop. Mainly
> for backward-compatibility with Flex/Flash, Royale has had x and y in the
> API since the beginning. I think it is a bug that x and y do not act like
> they do in Flex and plan to fix that after this release. Thoughts? I'm a
> bit concerned of the expense of calculating x and y because you have to
> check if the offsetParent is your immediate parent and get the
> offsetLeft/offsetTop of the immediate parent, but I think that's what it
> would take to fix it.
>
> Similarly (well, sort of), Flex did not support CSS margins, only padding.
> The browser reports width (offsetWidth) as factoring in content, padding
> and borders, but not margin. I think that's right, and matches Flex.
> However, our custom layout algorithms do not currently factor in margins
> since they are not reported in width. I think our custom layout should
> request width and margins and do the math. We should not change width to
> include margins. Thoughts? This will make our custom layout code a bit
> more expensive as well as it will probably need to call
> getComputedStyles() on all of the children in order to get margins. This
> is also something to fix in the next release.
>
> Of course, I could be wrong. Thoughts?
>
> -Alex
>