Skip to main content
F
FunkyJunk
Inspiring
October 21, 2013
Answered

Render Modes, Stage3D and Starling = confused.com

  • October 21, 2013
  • 2 replies
  • 2521 views

I’ve finally got round carry out a bit of research on different Render Modes and Starling, as I think I’m going to have to port a project over to Startling hopefully get some better performance.

However, after spending some time reading various articles, I’ve found myself in a bit of a confused mess.

My understanding there are 3 renders modes:

1-CPU

2-GPU

3-DIRECT

CPU, BOTH Compositing and Rendering are handled by the CPU/software

GPU, Compositing is handled by the GPU/hardware and Rendering is still handled by CPU/software

DIRECT  Compositing is handled by the CPU/software and Rendering is handled by the GPU/hardware.

However I'm slightly confused to how Stage3D fits into picture.

Is the following statement correct:

When the RenderMode is set to Direct adding Sprites into the (standard) display list doesn't necessarily take advantage of the GPU. To gain full leverage, the Sprite has to be added to the Stage3D display list. And as the Stage3D APIs are complex and low-level it is best to use a framework like Starling that uses familiar APIs. The low-level Stage3D  APIs run on top of OpenGL and DirectX on desktop and OpenGL ES2

Is that statement is true, then great, but what the hell do the other render modes do then?

If the RenderMode=GPU and I use the standard display list, what actually is happening, vs if I use the Stage3D display list?

This topic has been closed for replies.
Correct answer Aaron Beall

I'll take a stab at this...

I think your understanding of GPU is a little off... when you use GPU, it will render the classic (vector resterizer) display list using the GPU. Stage3D is always rendered using the GPU, while Stage (non 3D) can be rendered with the CPU or the GPU -- but GPU comes with many caveats (check out this list of things that don't get rendered at all.) The problem is that GPUs are optimized in ways that the stage display list is not designed for, and the stage display list is designed for things the GPU is not optimized for.

Also to tweak your statement, a Sprite (aka flash.display.Sprite) can ONLY be rendered on the classic display list (stage, not stage3d.) Stage3D is so low level that the Flash Player doesn't even have a Sprite equivalent for Stage3D -- that's where the Starling framework came from: a need for a higher level display model that was compatible with Stage3D.

Basically the GPU mode came around as a way to try to speed up the classic display list, and while it works well for some very specific use cases, overall it was limited (see list) and if not used properly could actually make performance worse. So Adobe decided to just start from scratch, and thus Stage3D was born: a rendering engine built from the ground up, designed and optimized specifically for GPU rendering (3D being a natural outworking of that, but just as applicable for GPU 2D rendering.)

This documentation is pretty enlightening on what GPU mode is doing under the hood:

http://help.adobe.com/en_US/as3/mobile/WS5d37564e2b3bb78e5247b9e212ea639b4d7-8000.html

Hope that helps!

-Aaron

2 replies

zeh
zeh
Inspiring
October 22, 2013

In a nutshell:

* Always use "direct", especially if actually using Starling (otherwise it limits somewhat what you can do).

* For "normal" Flash stuff, GPU works well if you more or less plan accordingly (e.g. use lots of Bitmaps) but some things are terrible on it (scrollRect) so you may need to use CPU mode instead. You'll probably need to test.

A
Aaron BeallCorrect answer
Inspiring
October 21, 2013

I'll take a stab at this...

I think your understanding of GPU is a little off... when you use GPU, it will render the classic (vector resterizer) display list using the GPU. Stage3D is always rendered using the GPU, while Stage (non 3D) can be rendered with the CPU or the GPU -- but GPU comes with many caveats (check out this list of things that don't get rendered at all.) The problem is that GPUs are optimized in ways that the stage display list is not designed for, and the stage display list is designed for things the GPU is not optimized for.

Also to tweak your statement, a Sprite (aka flash.display.Sprite) can ONLY be rendered on the classic display list (stage, not stage3d.) Stage3D is so low level that the Flash Player doesn't even have a Sprite equivalent for Stage3D -- that's where the Starling framework came from: a need for a higher level display model that was compatible with Stage3D.

Basically the GPU mode came around as a way to try to speed up the classic display list, and while it works well for some very specific use cases, overall it was limited (see list) and if not used properly could actually make performance worse. So Adobe decided to just start from scratch, and thus Stage3D was born: a rendering engine built from the ground up, designed and optimized specifically for GPU rendering (3D being a natural outworking of that, but just as applicable for GPU 2D rendering.)

This documentation is pretty enlightening on what GPU mode is doing under the hood:

http://help.adobe.com/en_US/as3/mobile/WS5d37564e2b3bb78e5247b9e212ea639b4d7-8000.html

Hope that helps!

-Aaron

F
FunkyJunkAuthor
Inspiring
October 22, 2013

Thanks Aaron that helps clear it up!!

There's only one thing left, that's aiding my confusion - RenderMode=GPU vs Starling  - http://esdot.ca/site/2012/runnermark-scores-july-18-2012 this report is showing GPU as similar performance to Starling... !!?

zeh
zeh
Inspiring
October 22, 2013

I think it depends on what you're doing. Going the Starling path means you're doing things in an extremely different way, but you have more control. The GPU path means things are easier (more "automatic"), but you don't have that much control over what's being done.

A simple benchmark can only test so much. If you take a generalized case like that, you get a solution that serves well in a general case as the winner. But if you really need the best performance, would you use something that works reasonably well in most cases, or something that works great in *your* specific case?

I've been with my head in this for a couple of months doing this very decision (building the same thing using "standard" Flash, and Starling), and in the end after a lot of benchmarking opted with Starling. Using Stage3d/Starling is crazy, but it's perfect if you know what you're doing. Doing quad batches and using the same texture for several different elements (reducing draw calls) means that a properly optimized Starling/Stage3d solution can easily beat an automatic GPU render just because of the unlikely corners you can cut when controlling the hardware; having GPU shaders available means you can go nuts with some effects with next to no performance cost; and hard-coding everything into textures mean you're forced to have your memory consumption down.

But again, this depends on what you're building, because you have to plan ahead, as it also has its own set of problems (e.g. masks are a pain in Starling, while GPU mode probably just falls back to a good performant software composition; text is a mixed bag; vector drawings that change every frame is a no-no; etc).

If you're doing standard Flash interfaces, GPU with some little planning is more than good (and easier to build). Game content or game-like interfaces where you need to squeeze the most power out of it... yeah, Starling/Stage3d for sure.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices