Prioritizing calculations per Frame

Design Performance
#1

@talves and @oldschooljarvis were discussing about prioritizing calculations per frame, in two ways:

  1. Have updates that we’d like, if we can, but we can discard if we don’t have time
  2. Detail / accuracy. If we’re running out of time, do an update with cheaper calculations.

This is quite a cool idea, and actually pretty easy. You can see for example in the main famin loop (still not ready yet :)) that we do actually track frame time in each loop and if we’re running over time, pause the dequeue, draw a frame and resume after.

I actually got this idea from Famous 0.3.5, but amazingly it was absent in the rewrite. The technique works amazingly well! I used it also in famous-views and the difference was very noticeable.

Anyways, point being, just like we provide NodeComponent update() functions with a DOMHighResTimestamp, we could also provide them with variables describing or relating to the current dequeue status, e.g. TIME_GREAT, TIME_OK, TIME_BAD, or something. That’s very easy to do and then the developer can use or ignore that info (by default, of course, everything runs).

#2

That’s an excellent idea.

Famous only provided requestUpdate() and requestUpdateOnNextTick(), allowing for exactly two scenarios: the component is a priority, or it isn’t. There was no practical reason to change from one to the other unless you knew ahead of time the component would incur a performance cost in a particular mode of operation.

Components/plugins that change their behavior based on actual performance metrics seem very interesting.

#3

@trusktr:

@gadicc @oldschooljarvis Does this slow down the rate in which the 3D world’s time passes, making objects appear to be moving slower?

Totally depends on how the component is written (which is great). E.g. famous’ example “Spinner” component, which just did rotateX++ on each tick, would slow down like this. But transitionables use the current time to calculate position per frame, so a few dropped frames could potentially go unnoticed.

Back to the original idea, it might be better to actually define in advance function priority. This could be used instead of or in addition to the TIME_OK idea. It starts getting a bit complicated, but of course is completely optional and only an avenue for those wishing to truly optimize performance. I was thinking:

  1. MUST_RUN: the queued function must be run in (every) tick, always (e.g. animation in foreground)
  2. SHOULD_RUN: run the func if we have time, otherwise throw it away (e.g. animation in background).
  3. MUST_RUN_EVENTUALLY: the func must be run, be it can happen the next tick (e.g. change a DOM class, or final position/frame of an animation).

Names up for discussion of course… but this kind of model could really help with performance, with situations where we discussed in the channel where e.g. foreground (in the scene) animations could be running at true 60 fps where less visible stuff in the background could be running at less.

#4

Sounds great. From a UI component standpoint I think you will usually want to drop frames instead of waiting for a laggy animation to finish. I was thinking of the timestamps as well and be able to drop messages that didn’t came back in time (or simply clear the remaining queue on every cycle, cheaper to do then time comparison probably).

The proposed tags like TIME_BAD are great for analysis as well. We could maybe provide a visual overlay of elements that are causing lag… (Not sure how though without impacting fps as well).

I really think that if we can provide intelligent tools to allow a frontend developer to analyse his performance we make everyone smile. In the end any powerful framework can be brought down to its knees with poor user implementation. Helping people to see where they can improve would be really powerful.

#5

Apply an outline CSS property, which won’t affect performance or the layout. It wouldn’t be available for WebGL things though. Perhaps that can be built onto the WebGL classes.

#6

:+1: For a great performance monitoring tool. Also might be great to create a benchmark plugin to the design as well.

1 Like
#7

:thumbsup: wow, I didn’t even know it existed… (Blushing)

1 Like