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 <[email protected]>:
> 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 <[email protected]> wrote:
> >
> > I managed to more or less double the performance on this…
> >
> >> On Mar 26, 2018, at 1:21 PM, Harbs <[email protected] <mailto:
> [email protected]>> 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
