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
