royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Layout optimizations
Date Tue, 27 Mar 2018 04:38:12 GMT
Fundamentally, Royale should not force anyone into one way of thinking or
the other regarding layout and css or really anything.  This is why I'm
not in favor of putting any deferred computation in the core.  I think the
key discovery so far is that LayoutBase was forcing every layout to
compute the width/height.  That does not fit into the above philosophy.
Let's remove that, and fix the layouts that were counting on it.

It will be totally fine of some layouts go back and set width/height or
even position:absolute and left and top.  Other layouts should just set
display and let the browser do the work.  The key thing is that the code
should not make assumptions.  Can we just agree to do that?

For those layouts that need to read back a value, feel free to keep
experimenting with ways to optimize it, but I still don't think any of
that needs to go in core.  It could go in some other base class above
LayoutBase to be used by those who need it.

I still don't get why deferral helps at all unless you can guarantee that
the code that reads these values will NEVER write a value that invalidates
the prior computation.  In the scenarios described, won't setting scale
invalidate the DOM?  Or setting a parent's width/height based on the
child's content?  I would think the main goal is just to try to coordinate
the reads (and cache them when possible) and then be smart somehow about
the writes.  I'm not clear you have to wait for a later event, maybe just
add to a queue that gets called at the end of layout as we have it today.

IMO, there are two valid scenarios: react to browser window size changes,
and react to content size changes.  I'm not 100% sure, but I think one can
be solved without the other and vice versa.  Our code may need to reflect
that so folks don't have to pay the price of looking for both scenarios if
only one is needed.  The LayoutChangeNotifier is a bead intended to allow
the Basic user to wire the one change event to the layouts that care
instead of having every layout care.  If folks haven't tried it, it might
be worth taking a closer look at it.
To try to summarize:  If we agree to not try any tricky deferral in
LayoutBase, remove the code that forced reading width/height for every
layout, see if we can display styles in NumericStepper and some other
places, and fix any layouts that break from this change, you can do pretty
much anything you want in other layouts.

My 2 cents,

On 3/26/18, 4:03 PM, " on behalf of Carlos Rovira"
< on behalf of> 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
>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.
>2018-03-27 0:42 GMT+02:00 Piotr Zarzycki <>:
>> 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
>> of web design let's try and see what happen.
>> Today I had pretty interesting chat with my friend who has deeper
>> about JS stuff. He said that too many people is going with the Flow
>> 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
>> in the future.
>> Thanks,
>> Piotr
>> 2018-03-27 0:22 GMT+02:00 Harbs <>:
>> > 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
>> > 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
>> >
>> > Harbs
>> >
>> > > On Mar 26, 2018, at 11:28 PM, Harbs <> wrote:
>> > >
>> > > With hard-coded values DOM interaction could be kept to a minimum.
>> > would be an interesting experiment to see what would happen if we
>> > rely on browser layout and hard code everything.
>> >
>> >
>> --
>> Piotr Zarzycki
>> Patreon: 
>Carlos Rovira

View raw message