Request for feedback: front-to-back renderer performance

Hi all,

I'm looking for feedback on the performance of the new front-to-back renderer introduced in r207. (See the r207 release notes for a brief overview of how it works if you missed it.) r208 fixed some bugs in the new rendering mode so it should be working reasonably well now.

I don't have many real-world games to test with. Artificial benchmarks are good to show the maximum difference it can make, but this is often much higher than would be the case for real games. For example the WebGL renderer can benchmark up to a whole 20 times faster than canvas2d in one artificial test we use, but for real games it's only up to 2 times faster - which is still great, but a long way off the artificial test result.

So if you're using r207+ could you give the front-to-back renderer a go and report back how it works for you? You just need to set 'Front-to-back renderer' to 'Enabled' in Project Properties (by default it is disabled).

The most important information to include is:

• the framerate in FPS both with and without the front-to-back renderer enabled
• the browser and OS version (e.g. Chrome on Android 5.1.1)
• the device model if mobile (e.g. iPad Air 2) or system spec if a PC
• the device GPU if you know it - use C2's rendererDetail expression to check this if you don't know (although only Chrome and IE currently support it)
• a brief overview of the kind of game

If you have multiple systems/devices, testing all of them would be much appreciated!

Note we're aware that some GPUs are actually slower in front-to-back mode. We'll probably have a front-to-back mode blacklist where it falls back to back-to-front mode only on certain GPUs. Adreno GPUs will probably be on this list, but your feedback may help identify others.

This information should help us decide whether to have front-to-back mode enabled by default in the next stable release. Thanks for your help!

Note: please don't report bugs with the front-to-back renderer here. I'm only looking for performance information. If you have a bug with the front-to-back renderer please report it to the Bugs forum following all the guidelines.

Decided to try it out with the last game I made (Dreaming Sarah) and here's a comparison.

Front-to-back renderer off

Front-to-back renderer on

My whole game uses a "effect" layer in which I have a single image (usually a fog) with a warp WebGL effect.

• Framerate was the same on/off
• Tried on NW.js and Chrome
• PC is Athlon II X4 630 2.80GHz 64bit , 6GB ram, GPU is Nvidia GeForce 750
• rendererDetail shows this ANGLE (NVIDIA GeForce GTX 750 Direct3D11 vs_5_0 ps_5_0) [Google Inc.] [front-to-back enabled]
• It's a 2D platform game

andreyin - if you have a bug with the front-to-back renderer please report it to the Bugs forum following all the guidelines. If it doesn't appear correctly the performance numbers are probably not useful either.

What if both are 60 fps, do you want the cpuutilisation %?

I use inspector to see what change, o dont see anything better

i just added a bug report on this related to extreme dropdown in fps and glitched view.

As far as i can see, in PC the fronttoback have a small difference with normal render, in my pc PhenomIIX4 with Radeon 6790 and W7. The difference is between 2-5 fps with normal games, and weird changes between 1-10 fps in heavy test (create 6000 objects with always jumping behaviour), the backtofront freezes in the jump instance, while fronttoback had 3 fps, so it's 3 frames better...

Did a quick test on a project and it was in the 20 to 30 fps range.

The game usually ran 55 fps, but really shouldn't be expected to benefit from front to back.

Its basically a bunch of tilemaps on a bunch of parallax layers set up like a starfield.

A few pixels overlapping other pixels rather than textures overlapping other textures.

More of a worst scenario basically.

I decided to run a test in three varying areas of my game to get a feel for how it handles. So for three sections of Courier:

Overworld section:

Back to Front:

~11,890 Objects, 60FPS, 70-85% CPU load depending on what I'm doing

Front to Back:

~11,800 Objects, 45-55FPS, 90-96% CPU load depending on what I'm doing

Effects range from low to medium-high depending on location, many objects but not always a lot moving, medium characters in one area.

Small Town Section:

Back to Front:

~1,335 Objects, 60FPS, 25-27% CPU load

Front to Back:

~1,335 Objects: 60 FPS, 30% CPU load

Effects-light, little movement, medium amount of characters

Dungeon with a lot of water and effects:

Back to Front:

~1850 Objects, 60 FPS, 68-75% CPU load

Front to Back:

~1850 Objects, 60 FPS, 70-80% CPU load

Effects-heavy, lots of moving objects, low amount of characters

Core i7 4770 3.4 GHz, 16 GB ram, GeForce GT 640 4GB

My game is typically composed of a lot of overlapping objects, so I would think it would be good candidate for Front to Back. I do have effects in some locations which may be negating gains. I also have layout-wide HSL and Exposure shaders for color correction, so that may be a problem with it too. I do get some rendering differences between them, but that's beyond the scope of this post.

Hmm... the browser capping the framerate at 60 FPS makes it hard to tell any difference. Maybe try closing all instances of Chrome and run again from the Start -> Run dialog as:

chrome --disable-gpu-vsync

Then you should get an uncapped framerate which makes for an easier comparison.

Fatal Crash (restarts the entire phone) on Huawei Honor2 when turning the cellphone (from landscape to portrait or viceversa), only happends if Front To back is on, never had this problem before in any kind of game...

I did a little testing and found the following results, using r208, Chrome, i7 with HD4600. The test was a fps throttle, target between 51-56 FPS by creating/destroying horizontally moving sprites (sine behavior).

Sprite image with zero opacity (animation frame 1):

-- B to F: 2260 sprites at 51 FPS, 9% cpu

-- F to B: 2900 sprites at 56 FPS, 9% cpu

Sprite image with approx 15% of surface < opaque (animation frame 0):

-- B to F: 2290 sprites at 51 FPS, 9% cpu (partial opacity makes no difference - as expected)

-- F to B: 1630 sprites at 51 FPS, 11% cpu (significantly lower performance)

Here's a link to the capx.

Here's what i got on macbook pro with retina late 2013, the game runs at full resolution (2560x1600) 11-15 fps on both of your tests and no difference, the only difference in cpu utilization, with ftb it's sometimes higher a bit. The same situation with other laptops with intel gpu, on old intel's GMA's the ftb mode crashes the app.

Picture

Desktop (Chrome, Windows 8.1, Intel Pentium Dual Core E5200 2.5 GHz, NVIDIA GeForce GTS 450 1 GB, 4 GB RAM):

~40-60 FPS regardless if the front-to-back renderer is enabled or not

Mobile (Samsung Galaxy Note 3 (SM-N9005), Chrome, Android 5.0):

~30-50 FPS with the front-to-back renderer disabled

~25-30 FPS with the front-to-back renderer enabled

The game I tested on is a 2D metroidvania platformer.

Hmm... the browser capping the framerate at 60 FPS makes it hard to tell any difference. Maybe try closing all instances of Chrome and run again from the Start -> Run dialog as:

chrome --disable-gpu-vsync

Then you should get an uncapped framerate which makes for an easier comparison.

That doesn't seem to change anything. It's still capped at 60. In fact, I don't even see the vsync flag anywhere in Chrome (canary/45 or 43). I wish I could give some better benchmarks, but I'm not sure of any way to show more than 60 FPS.

Gosh, this isn't sounding very good at all. Either our implementation isn't fast enough (and I'm not sure what we could do to improve it), or front-to-back rendering just doesn't work very well with real-world games.

Does anyone have any positive feedback at all?