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
