I was thinking that the solution might be as simple as dispatching layoutStart and layoutComplete events. We already have layoutComplete, and instead of blindly measuring, we can dispatch layoutStart. The parent layout can decide whether measuring is necessary or not.
I’d keep the LayoutManager, but it would only delay layout if measuring is in fact necessary. If not, the layout would get executed immediately. I’d pull all the sizing logic out of LayoutBase and I’d create a new AbsoluteLayoutBase which has all that kind of logic. I’m pretty sure this would enable lean browser-based layouts as well as robust absolute layouts as needed. Makes sense? (And yes, after Passover I hope to help with the emulation components.) Harbs > On Mar 27, 2018, at 7:51 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Harbs, > > My recommendations are to refactor LayoutBase so that folks who feel more > comfortable letting the browser do the resizing can. If you want to build > out a completely different set of layout classes that don't use the > browser at all, feel free to do so. Some folks will probably trust Royale > more if they can recognize common patterns in the DOM for layout, > regardless of performance. I'm having trouble believing that every > production JS app has had to use absolute positioning to get satisfactory > responsiveness. > > I do not think we have the people power to try to write and debug every > one of our layouts to use absolute positioning at this time. I am hoping > you can get your app up to sufficient speed soon and then can help us > write emulation components instead of trying to optimize all of our > existing layouts. > > Thanks > -Alex > > On 3/27/18, 12:37 AM, "Harbs" <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>> wrote: > >> Again: I’m not arguing that we should not have layouts which encapsulate >> common website practices. Simple can sometimes be good, but simple is not >> always the same as performant. Your assumption that native browser layout >> is fastest is simply not true. The browser generally needs to do a full >> sweep every time it calculates layout. >> >> Did you run a performance timeline on those examples you linked to? Try >> resizing the window and you will see how jerky the layout actually is. >> Each re-render takes considerable measurable time. >> >> Compare that to something like GSAP[1]. GSAP has hands-down the best >> performance on HTML animations.[2] One of the main reasons is because >> EVERYTHING is set using absolute positioning and does not rely on browser >> layout at all. GSAP has a crazy amount of javascript to calculate how big >> and where (and color, etc) everything needs to be on each animation >> frame, but it’s smooth as silk. >> >> Additionally, there are many cases where we need to get size and position >> using javascript. Some examples: Drawing a hover effect over an item >> renderer — or better: getting the position for drag and drop while >> changing visuals as the drag indicator moves around. Animations (and many >> animations are difficult or impossible to create by just using css. My >> app has no end to the number of places where I need to get position. In >> short, the average website will probably not need very much in terms of >> recalculating and css can be a good option for that, but many >> applications will and will probably need absolute positioning to get the >> best performance. >> >> Harbs >> >> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreens >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreens> >> ock.com >> <http://ock.com/>%2F%3Fexample%3Dsortable-grid-using-draggable&data=02%7C01%7Caharui >> %40adobe.com >> <http://40adobe.com/>%7C378707c0f7a1497ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c1 >> 78decee1%7C0%7C0%7C636577330724835817&sdata=W9eTpZiNTREiGLkV1gucROT8HhVSRu >> V7YmFEcdc8CFY%3D&reserved=0 >> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreens >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreens> >> ock.com >> <http://ock.com/>%2Fjs%2Fspeed.html&data=02%7C01%7Caharui%40adobe.com >> <http://40adobe.com/>%7C378707c0f7a1 >> 497ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63657733 >> 0724835817&sdata=wJ7Ug6lDNm1Dfl2YOV071tRyJgboCtJ%2FpuacMKxLFZE%3D&reserved >> =0 >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensoc >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensoc> >> k.com <http://k.com/>%2Fjs%2Fspeed.html&data=02%7C01%7Caharui%40adobe.com >> <http://40adobe.com/>%7C378707c0f7a149 >> 7ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365773307 >> 24835817&sdata=wJ7Ug6lDNm1Dfl2YOV071tRyJgboCtJ%2FpuacMKxLFZE%3D&reserved=0 >>> >> >>> On Mar 27, 2018, at 2:03 AM, Carlos Rovira <carlosrov...@apache.org >>> <mailto:carlosrov...@apache.org>> >>> wrote: >>> >>> Hi Harbs, Piotr, >>> >>> see this link [1] and [2] >>> >>> This are only CSS rules to layout content. Here you have all the use >>> cases >>> we could have in a Royale app. things inside things that layouts >>> responsively using percentage widths (see width:75% in examples and how >>> this resizes with the resize of a window, and more... Don't see nothing >>> we >>> must do that is not there. And is only CSS. So my point is: >>> >>> 1.- They are using the browser layout implementations vía CSS or in >>> other >>> words the native rendering engine of a browser, and that's without doubt >>> the most performant we can go >>> >>> 2.- This is accomplished in the most easy and simple way to go that is >>> through CSS code without any JS programing. >>> >>> So, finaly, we only need to do as easy as that. generating good simple >>> html >>> and css. We already did that leveraging MDL (and only encapsulating what >>> mdl people did), now is what I do with Jewel, trying to put that >>> knowledge >>> and the standards things I see in encapsulated patterns to make it easy >>> to >>> program in Royale. >>> >>> So again, I continue without know what we need that is not there. Since >>> if >>> in that examples we have all things...we're done...we only need to >>> encapsulate it in Royale as css and make it accesible vía Royale API, >>> and >>> we don't need to deal with any complex programmatic code. >>> >>> Maybe I'm missing something here. >>> >>> Thanks >>> >>> [1] >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3sc >>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3sc> >>> hools.com >>> <http://hools.com/>%2Fw3css%2Fw3css_responsive.asp&data=02%7C01%7Caharui%40adobe.co >>> <http://40adobe.co/> >>> m%7C378707c0f7a1497ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7 >>> C0%7C0%7C636577330724835817&sdata=pZVupqKYaJ9gLEdexwtizNMI%2FhaVssJJgGwyf >>> Xd64hQ%3D&reserved=0 >>> [2] >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3sc >>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3sc> >>> hools.com >>> <http://hools.com/>%2Fw3css%2Fw3css_layout.asp&data=02%7C01%7Caharui%40adobe.com >>> <http://40adobe.com/>%7C >>> 378707c0f7a1497ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7 >>> C0%7C636577330724835817&sdata=bhwYmvCk7X3YuAynbvnWL9yC%2FXx82zph1FZ3e7h0T >>> VA%3D&reserved=0 >>> >>> >>> >>> 2018-03-27 0:42 GMT+02:00 Piotr Zarzycki <piotrzarzyck...@gmail.com >>> <mailto:piotrzarzyck...@gmail.com>>: >>> >>>> Reading Harbs and his real world example maybe that approach with >>>> saving >>>> some values is a big winner for Royale. Instead going with the current >>>> Flow >>>> of web design let's try and see what happen. >>>> >>>> Today I had pretty interesting chat with my friend who has deeper >>>> knowledge >>>> about JS stuff. He said that too many people is going with the Flow >>>> which >>>> has been served by bigger players like Facebook - React etc. Although >>>> it is >>>> pretty awesome framework it's just failing when you have BIG fat >>>> complex >>>> application, where performance is important, not saying about quality >>>> of >>>> code. >>>> >>>> I see we may win on all of that fields. Maybe different approach is >>>> solution, instead blindly believe in the browser and better >>>> implementation >>>> in the future. >>>> >>>> Thanks, >>>> Piotr >>>> >>>> 2018-03-27 0:22 GMT+02:00 Harbs <harbs.li...@gmail.com >>>> <mailto:harbs.li...@gmail.com>>: >>>> >>>>> Case in point: >>>>> >>>>> In my app, I’m using OneFlexibleChildHorizontalLayout which uses >>>> flexbox. >>>>> Great. No need for writing values. Right? >>>>> >>>>> Not so fast. >>>>> >>>>> I have fit to view functionality in my app which needs to get the >>>>> size of >>>>> the flexibleChild which is the container to figure out how much to >>>>> scale >>>>> the content. The entire fit function takes 36 ms to run. The height >>>> getter >>>>> on the flexibleChild *alone* takes 14 ms. If the size of the >>>> flexibleChild >>>>> was hard-coded, the getter would not take measurable time. >>>>> >>>>> I have tons of hard coded size and positioning of SVG in my app >>>> (literally >>>>> hundreds of DOM objects) and it runs ridiculously fast compared to all >>>> the >>>>> Recalculate Styles which are caused by default browser layout. >>>>> >>>>> I’d really love to get some hard numbers from comparing the >>>>> approaches. >>>>> >>>>> Harbs >>>>> >>>>>> On Mar 26, 2018, at 11:28 PM, Harbs <harbs.li...@gmail.com >>>>>> <mailto:harbs.li...@gmail.com>> wrote: >>>>>> >>>>>> With hard-coded values DOM interaction could be kept to a minimum. It >>>>> would be an interesting experiment to see what would happen if we >>>>> *don’t* >>>>> rely on browser layout and hard code everything. >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Piotr Zarzycki >>>> >>>> Patreon: >>>> *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa> >>>> treon.com >>>> <http://treon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >>>> <http://40adobe.com/>%7C378707c0f7 >>>> a1497ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365 >>>> 77330724835817&sdata=SlwXFmttSOExzUOXuifgGWea%2BLqIF0mIX2ImQsVSU9w%3D&re >>>> served=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa> >>>> treon.com >>>> <http://treon.com/>%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >>>> <http://40adobe.com/>%7C378707c0f7 >>>> a1497ee34b08d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365 >>>> 77330724835817&sdata=SlwXFmttSOExzUOXuifgGWea%2BLqIF0mIX2ImQsVSU9w%3D&re >>>> served=0>* >>>> >>> >>> >>> >>> -- >>> Carlos Rovira >>> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me% >>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%> >>> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com >>> <http://40adobe.com/>%7C378707c0f7a1497ee34b08 >>> d593b5a50b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63657733072483581 >>> 7&sdata=bWTM21tcBignH1Kcd%2FdpZfqbygDtkjURRLgo9hYoM%2FM%3D&reserved=0
