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:carlosrov...@apache.org> Sent: Thursday, February 8, 2018 12:33 PM To: dev@royale.apache.org<mailto:dev@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 <yishayj...@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.li...@gmail.com> > Sent: Wednesday, February 7, 2018 6:24 PM > To: dev@royale.apache.org<mailto:dev@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 <p...@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.li...@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 <aha...@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
