Stage size and performance


#1

My game is a Flash to HTML5 port, it’s nominal size is 760x630px, and even without additional WebGL optimizations (like Tilemaps) it shows 60 fps in most browsers even on my 6 years old laptop.

But… I’ve changed the game <div> to occupy 100% of the browser window, so at 1920x1080 screen resolution the stage size is now around 1920x916px: everything around the main game sprite is either a solid or tiled background.
And now this is a problem even for my gaming PC, which can hardly support a plank of 40 fps!

As I explain it, the slowdown is due to all background pixels being redrawn on every frame. Unless I’m wrong, of course, what secret optimizations can be conducted to prevent this static graphics from consuming so much rendering time?


#2

Do you force -Dcanvas rendering?

What do you primarily use to render? The display list, sprite.graphics, BitmapData, or something else?


#3

No!

90% is BitmapData.


#4

You mentioned that “static graphics” were consuming a lot of your performance. Are you modifying the pixels of your BitmapData objects, or are you only using Bitmap objects to display unmodified BitmapData objects?

How many bitmaps do you think you have on the screen?


#5

I modify BitmapData objects only on screen resize (to retile the background).
But I tested it without any background images at all - it’s the same performance drop.

Around 20.


#6

See this video: https://youtu.be/qJEfROaoqUc
Reels spin ~4x faster when the window size is small.


#7

You could use a non-resizable window, and scale it up using CSS only. If <window resizable="false" /> in your project.xml, then we’ll try not to scale up our canvas backing, and the browser will do the scaling instead.

I wonder, though, if you are running in canvas for some reason instead of WebGL. Could you try adding trace (openfl.Lib.current.stage.window.context.type); and seeing what it outputs?


#8

Its webgl.

So, the slowdown is related to the size of the canvas, and it is not OpenFL-related?


#9

It might be, though WebGL is usually less sensitive about this