Will Chrome 18's SwiftShader slow down 2D games?

[AshleyScirra]

Hi all,

I'm from Scirra, developers of a HTML5 game creator for Windows, at
www.scirra.com. We have lots of users with lots of games made in our
engine on the web.

It's exclusively for 2D games, but in benchmarks we found WebGL to be
2-3 times faster than Canvas 2D so we have already implemented (and
lots of games are already using) a WebGL render to display 2D
content. At startup, it *always* chooses WebGL if available on the
assumption it is hardware accelerated, then falls back to Canvas 2D if
not available.

While I'm sure the SwiftShader software renderer for WebGL is very
useful for some, I'm worried about the impact on our games. Will
Chrome be using a slow software rendered WebGL when it could be using
a GPU accelerated Canvas 2D? Are there setups in the wild where the
Canvas 2D is GPU accelerated but WebGL not available? If so,
introducing SwiftShader will cause serious performance regressions for
many of our HTML5 games.

We don't have a big testing lab or anything so we can't tell
ourselves, so is that going to happen? If so, is there any way to
detect if Chrome's WebGL implementation is hardware-accelerated or
not? Some users will have unplayable levels of performance unless we
can accurately pick the fastest renderer out of Canvas 2D and WebGL.

Thanks,

Ashley Gullen
Scirra.com

[Gregg Tavares]

On Feb 10, 6:10 pm, AshleyScirra <ashl...@gmail.com> wrote:
> Hi all,
>

> I'm from Scirra, developers of a HTML5 game creator for Windows, atwww.scirra.com.  We have lots of users with lots of games made in our

Unfortunately I think the short answer is "probably yes, if you choose
WebGL and it happens to be software WebGL it might run slower than if
you had opted to use canvas".

We've had many discussions with developers about this problem but
unfortunately we haven't come up with a good solution yet. While it
might seem as simple as being able to query "software" vs "hardware"
there are plenty of slow GPUs and plenty of fast CPUs such that adding
a query to tell if WebGL is hardware or software is not really the
correct answer. Ideally you'd like to know "is WebGL fast for my
application or slow for my application" and the reality is that that
will be a different answer for every application.

While we are looking into other solutions like a fast/slow query,
right now my best recommendation is to add some short benchmark to
your games for new users. This is what MapsGL does. If you haven't
visited Google Maps in a while or seen MapsGL it uses WebGL. If you go
to maps.google.com you'll see in the bottom left area a button to try
MapsGL. Clicking that button does a quick benchmark to see if your
machine is fast enough. If it determines your machine is not fast
enough you're still given the option to try it if you'd like.

Maybe others have a better ideas but for now I suspect a similar
solution is all I can recommend.

Gregg Tavares


> Thanks,
>
> Ashley Gullen
> Scirra.com

[AshleyScirra]

Thanks for the reply Gregg. I was under the impression the software
renderer could only beat low-end GPU performance with a really
powerful multi-core CPU, which seems like an odd setup. Also in the
past I've noticed Chrome's Canvas 2D software renderer is no slouch
either, so my preference would be to not use WebGL if it's software
rendered. A vendor-specific extension would do the job here, like
"window.webkitIsAcceleratedWebGL". Is this really off the cards?
It's going to be a real pain if lots of users start reporting
performance regressions to us...

Ashley


On Feb 11, 3:05 am, Gregg Tavares <g...@chromium.org> wrote:

[Darin Fisher]

It probably helps that H/W Accelerated 2D Canvas is disabled on
Windows XP, and on Windows 7, the support for H/W Accelerated WebGL is
generally quite good.

-Darin

On Feb 10, 6:10 pm, AshleyScirra <ashl...@gmail.com> wrote:
> Hi all,
>

> I'm from Scirra, developers of a HTML5 game creator for Windows, atwww.scirra.com.  We have lots of users with lots of games made in our

[Nat Duca]

Keep in mind that its a wild world out there, especially if you consider

  (A) mobile, whose GPUs can can be much worse perf wise on 2D rendering workloads than the equivalent CPU workload, and

  (B) corporate computers, which are typically CPU heavy and GPU-light

  (C) people browsing the web while they have some GPU or CPU-intensive app in the background, say, WoW, or even something as simple as a music player.

Personally, the software backend for WebGL is just part of this wild wild world. Solve the problems above and software webgl will fall naturally out of your solution.

The thing to keep in mind with all graphics is that performance is highly dependent on *what* you are drawing and how that matches up with the underlying hardware. Just as a concrete example, a thousand sprites perform radically differently depending on whether you have a PowerVR GPU or an ATI/NV/Intel GPU. On lowend ATI/NV/Intel GPUs, software might actually be a win in this case.

The only way to be sure that you're giving your user the best experience is to make the choice at runtime. :)

My advice is to pick some "representative content" that your application typically uses, in Scirra's case, perhaps the actual sprites from your demo, just done offscreen and with fake solid-colored textures that you synthesize in JS rather than download. Try rendering it both with canvas and webgl. Don't draw them and time the drawing --- run a real requestAnimationFrame based loop to an offscreen canvas for a few iterations (~10)! Browsers do funky things behind the scenes that you wont catch if you just time the drawing, and doing it this way means the UI will feel responsive while the benchmark is happening.

For bonus points, store which wins on your sesssion and/or local storage. :)

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-discuss