Hi Harbs,

I think the performance optimizations you describe are great, now that you
get to that point, I'd like to know if some of the calculations we have in
the layout algorithm could be removed and delegate to some CSS rule
attribute that make the same. I imagine that delegating to browser native
code should give us better times, and as well will make our code less
complex and with potentially less instructions and loops to do. Maybe a mix
of optimized layout algorithm + css layout rules is the way to get the best
performance.

thanks!

2018-03-26 18:21 GMT+02:00 Harbs <harbs.li...@gmail.com>:

> Hi Carlos,
>
> There’s one thing to consider here which is really important in my opinion:
>
> All the major frameworks (i.e. React, Vue, etc.) have Virtual DOM
> optimizations because direct interactions with the DOM (be it elements or
> CSS) is painfully slow. This is true for both reads and writes. Mixing
> reads and writes is even worse, because it forces reflow, but even without
> forced reflow, the more interaction with the DOM, the slower your app will
> be.
>
> Royale has a huge advantage over the other frameworks because they need to
> use diffing to sync their virtual DOM with the real DOM. In Royale, we wrap
> the real DOM in our components which can act as a “wrapper” virtual DOM. We
> don’t need diffing and we don’t need to find the DOM elements in the tree
> (which can cause more performance problems) because we have direct
> references to the actual DOM element.
>
> When necessary, we can and should access the DOM element to write and read
> what we need, but we should identify performance bottlenecks where we
> should avoid accessing the DOM elements directly when possible. x, y, width
> and height are four areas which my tests have shown huge differences by
> avoiding direct DOM interactions. My optimizations have reduced the
> rendering time of the RoyaleStore app starting from the Application.start()
> until the rendering finished from 340 ms down to 220 ms. This is mostly due
> to removing layout thrashing and avoiding direct access of x, y, width and
> height.
>
> I think there’s a lot more work to do in this area, but I think we should
> be abstracting more of the DOM away and not less…
>
> My $0.02,
> Harbs
>
> > On Mar 26, 2018, at 6:51 PM, Carlos Rovira <carlosrov...@apache.org>
> wrote:
> >
> > Hi,
> >
> > just get the time to read the whole thread and now I want to say some
> > things.
> >
> > First, Harbs, thanks for working on this. I think this topic is super
> > important since if we don't get smooth apps in desktop and mobile, we're
> > losing our time here, since nobody will use Royale in the end. So Layout
> > performance is critical.
> >
> > Then, most of us are working with little example apps, or most complex
> > royale examples actually are not using resizings and other layout
> changes,
> > so is difficult to measure how is the actual way of doing things. The
> only
> > reference I have is with Harbs app posted several months ago. In that
> case,
> > in desktop performs ok, but trying in mobile (and considering it wasn't
> > optimized for mobiles and tablets), the performance was not good. I
> assume
> > the problem was multiple: at that time Flexjs still more alpha than
> Royale
> > now, a first huge app, no optimizations in framework and the app, and
> maybe
> > created at that time with desktop in mind (no mobile devices).
> > So it's clear that we need optimization, and as well Harbs created the
> app
> > with a way to solve the problems he had with the current tools he had at
> > the moment and maybe that's the best way. Don't know since I don't know
> how
> > that Code is done.
> >
> > In the other hand, I'm a huge advocate of some of the things Alex said
> > below. The way I see Royale is as a way to encapsulate common patterns
> and
> > to get the best more simple DOM possible that works better. And for me is
> > DOM combined with CSS.
> >
> > In the example posted by Alex:
> >
> > <body>
> >  <div>
> >    <span style="display:block">type below...</span>
> >    <input />
> >  </div>
> > </body>
> >
> > I agree with in all that output but not in the style attribute for me it
> > should be remove and have a css rule that setup the display:block for the
> > span.
> >
> > So we don't need to follow exactly what Flex did. In fact we're changing
> > lots of things for Royale, like introducing strands/beads, and many other
> > things.
> >
> > For that reason things like LAYOUTS, TRANSITIONS and STYLES are something
> > that the browser puts in CSS and we should do the same. In other words:
> I'm
> > confident that browser vendors optimize how HTML, CSS and JS renders and
> > works between them. So this means again that our mission is to create the
> > best, optimal and simple HTML/CSS/JS we can. That's the power we can
> > provide to our users, and we must trust in how browsers will perform
> since
> > they are responsible of the rendering engine.
> >
> > So in the we shouldn't do much code, checking, loops, and more and should
> > trust more in media-queries css rules and attributes and so.
> >
> > For example, for responsiveness we should not have any code in a layout,
> we
> > should introduce a CSS media-query that will be responsible of change the
> > rendering as the user executes the app in desktop, mobile or tablet.
> >
> > That's the same reason why I try to remove in Jewel all "style"
> attributes
> > in components and making that components to have the same information in
> > it's own css rule attribute set as a class, since we see in all browser
> > apps out there written in other popular frameworks that's a good practice
> > and encourages separation of concerns while it should perform right since
> > browser vendors are optimizing that. So for me, a concrete component has
> > CSS rules that sets display to block, inline-block, ... or position to
> > absolute or relative and more, and I think that's the same for
> transitions.
> > I don't expect to write transition javascript code, since I expect to
> setup
> > in AS3/MXML and that code implies to assign a css rule that set up the
> > standard CSS transition code.
> >
> > So returning to royale, I think we'll gain the performance battle if we
> can
> > make royale to write apps that :
> >
> > - uses HTML to declare components (with attributes), "layouts"(that's the
> > divs that holds other comps), and maybe no more
> > - uses CSS to declare display, layout, transition, styles (colors,
> > lines,...) since that's its responsibility
> > - uses JS to make code, but not whatever code!, just the one that is
> needed
> > for the app and to "bind" things together.
> >
> > For example, we should ask ourselves if width, explicitWidth should be
> > delegated to CSS since is where sizes are better handled.Maybe we are
> > trying to do that in JS, and maybe that's not the actual way of doing
> > things out there. So we should not try to force the browsers to do things
> > they are not prepared to.
> >
> > That's the way I see this, regarding HTML output. SWF is another beast
> that
> > should be covered as well to see how to become part of all of this.
> >
> > My 2ctns! :)
> >
> > Carlos
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2018-03-26 14:43 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> >
> >> Another bottleneck I’ve observed is the use of Language.is and
> >> Language.as. Each call is pretty cheap, but they all add up — especially
> >> calls which use interfaces.
> >>
> >>> On Mar 26, 2018, at 3:37 PM, Harbs <harbs.li...@gmail.com> wrote:
> >>>
> >>> I managed to more or less double the performance on this…
> >>>
> >>>> On Mar 26, 2018, at 1:21 PM, Harbs <harbs.li...@gmail.com <mailto:
> >> harbs.li...@gmail.com>> wrote:
> >>>>
> >>>> Another interesting study is NumericStepperView. NumericStepperView
> >> strand setter takes 12.6 ms to run on a single component! There are many
> >> subsequent DOM read and writes in that component causing it to take much
> >> longer than necessary to render. I’m going to make some changes to the
> >> class which should vastly improve performance on that.
> >>>>
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to