Stats showing actually rendered frames about starling-framework HOT 8 CLOSED

What do you think of that?

I also really liked your proposal of adding a new SKIP_FRAME event, so I added that, too. Thanks so much for the suggestion!

from starling-framework.

Thanks a lot for the suggestion, Jean-Christophe! I agree – in some situations, it would be more useful to see the actual frame count without the skipped frames. I think my reasoning behind the green color (vs. showing the actual number) was that I thought it would be sufficient in most cases, while not distracting as much from the pure "how many frames are there" information you typically need. If the FPS number had suddenly shown, say, 20, while you target 60 fps, it would have been confusing for users.

What we could also do, along the lines of your idea, is to add a new line that counts only the skipped frames. So, a game targeting 60 fps would still show "60" in the FPS line, but e.g. "40" as "skipped frames/sec".

What do you think of that?

from starling-framework.

add a new line that counts only the skipped frames

Yes, more stats sounds even better.

Along with the idea, I was looking into a way to get the data from Starling about rendering stats, without hacking into Starling source code. It would be useful, for example, to get full performance data into my analytics.

There is an Event.RENDER event. It is only triggered when a frame is not skipped, so doesn't give the actual FPS (one might assume Event.RENDER is triggered when render() is called).

I could add events Event.SKIP_FRAME (and Event.DRAW_FRAME which would be more explicit, but would do the same as Event.RENDER).

Or/and add skipCount to the Painter? So it exposes both frameCount and skipCount.

Or/and add a function get stats():Stats with class Stats { ...data from StatsDisplay... }.

from starling-framework.

Note that "skipped/sec" is typically two frames lower than the "frames/sec" – that's because the stats display renders two times per second. 😉

from starling-framework.

What do you think of that?

Great!

"skipped/sec" is typically two frames lower than the "frames/sec"

OK, so that's only when the stats are displayed, good to know. I assumed there was a built in minimum of the refresh rate.

Maybe there is a way to know the frame was only drawn because of the stats display? This way it could still counts as a skipped frame. No need to over-complicate things just for that though.

from starling-framework.

Thanks for your quick review, Jean-Christophe! 😄

Maybe there is a way to know the frame was only drawn because of the stats display? This way it could still counts as a skipped frame. No need to over-complicate things just for that though.

Mhm, I thought about that, too; just as the number of draw calls shown ignores those of the stats display, it would be great if the "skipped frames" count would take the stats display itself into account. However, it's not so easy, because I don't know who or what is responsible for a draw call. E.g. there could be a TextField on the stage displaying the current time, updating in sync with the stats display. With the stats display enabled, it wouldn't even change the skip count.

So I guess all I can do is document this behavior, but keep it as is. 😉

from starling-framework.

Just a random thought I got on that.

Assuming displayObject.requiresRedraw indicates that a given DisplayObject is to be redrawn.

It might be relatively easy to implement (pseudo code).

/// @internal
DisplayObject.dirtyList(): Array<DisplayObject> {
  if (this.requiresRedraw) return [ this ] else return [];
}

/// @internal
DisplayObjectContainer.dirtyList(): Array<DisplayObject> {
  const ret = [];
  for (const obj of this.children)
    ret = ret.concat(obj.dirtyList());
  return ret;
}

That gives the list of objects that need redraw:

• good for debugging which object is responsible for redrawing the scene (when trying to improve that)
• allows starling check that only the stats display is responsible (when showing it).

from starling-framework.

Thanks for the suggestion, Jean-Christophe! You're right, it might be useful to add such functionality to be able to find out more about what's responsible for a redraw – and use that inside the stats display, too. I'll think about this!

from starling-framework.