Chrome 33 + WebGL performance

0 favourites
From the Asset Store
Original music compositions in the style of classic RPGs such as FFII-IV.
  • Hi all,

    Coincidentally Google released Chrome 33 today, the same day we did our r163 update.

    Previous betas changed the way we detect the very slow software-rendered WebGL mode in Chrome and some people reported worse performance. However Chrome 33 ought to support the new detection and ensure best performance for everyone.

    Can anyone who was affected confirm that Chrome 33 now correctly falls back to canvas2d instead of using a really slow WebGL mode?

  • No noticeable slow down for me.

  • Argh - still getting software rendering here.

    At this point I think you should release a 163.2 and reimplement the hack you had before to get it to avoid software rendering. I'm stuck on version 159 so I can keep using node webkit before it was switched to use chromium 32.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • After the update i loaded up my newest project (that was running fine yesterday) and performance was terrible. I just did the chrome beta update to 33 and it didn't fix the problem, however, I think I may be getting a couple of extra frames of speed. It's still not playable though.

  • Arima - is that in the Chrome browser at v33 or just in node-webkit?

  • Sorry I wasn't clear, both chrome 33 and node webkit in 163 are affected by the performance problem, same as chrome 32. Chrome 33 has resulted in no improvement and I'm still getting single digit fps when fullscreened. I was able to get 60 fps before in chrome 31/node webkit r159.

  • My project Orbit has recently taken a bit of a nosedive in performance recently, even still on Chrome BETA 33, and as we haven't added anything that would substantially reduce performance, in fact we've been optimizing. I even went through every collision event to check overlapping collisions were at the top as I thought it was the new collision cells that was causing the problem.

    It seems like a very recent thing for us, maybe over the last two weeks.

  • Guess I've been issues with 33 beta, upgrading to 33 stable right now. Hell, I didn't even have any issues with 32. Knock on wood...

  • Running Windows 8 64bit, with Chrome 33 (all chrome://flags in default) and r163 build. Chrome 33 browser defaults to webgl just fine. I have Configuration Enable WebGL On. At first it was defaulting to canvas2d and the FPS was at 36, but then I updated the GeForce drivers from 331.65 to 334.89 and it works great now. I'm getting a solid 60 FPS in both webgl and canvas2d with Chrome 33.

  • Arima: for node-webkit, could you try this? ...

    Extract the two .json files over the ones in <install dir>\exporters\html5\node-webkit. They should add commandline switches to prevent using Swiftshader, so ideally you'll get fast canvas2d instead of slow webgl in node-webkit.

    In the mean time I'm trying to find out from someone on the Chrome team if the new workaround should actually be working in Chrome 33 - I was told it ought to be working...

  • Oh and another thing to verify this really is the problem: try closing all instances of Chrome, then use the Run dialog (Win+R) to run:

    chrome --disable-software-rasterizer

    I think that disables swiftshader, but not sure if it has any other side-effects... anyway, if you then preview *in that Chrome window* that opened (if you close it it'll lose the setting), you should see the same thing: fast canvas2d instead of slow webgl. Can you confirm this is the case?

    If Chrome 33 does not support the new workaround and this fixes it, I'll do a .2 update since it will be a few weeks before the next update.

  • I tried both, and neither worked. The only thing that's worked has been enabling the flag to override the software rendering list in chrome://flags (ignore-gpu-blacklist).

  • It seems that chrome 33 has helped some people, at least:

  • Hmm... I tried adding --ignore-gpu-blacklist to the package.json and package-preview.json files you linked, and it didn't work, still getting software rendering.

    What does work, however, is making a shortcut to the exported exe file, right clicking it, and editing the properties so that the target is:

    "C:\path\nw.exe" --ignore-gpu-blacklist

    Then running the shortcut, I get 60 fps again. I tried modifying the shortcut to use --disable-software-rasterizer, but it still didn't work. Kinda odd that --ignore-gpu-blacklist doesn't work in the package file when it works in the shortcut.

  • I updated a galaxy tab3 yesterday from chrome 30 or 31 to chrome 33.

    An image heavy game developed last december, exported and hosted online ran decently at that time on that galaxy tab.

    After updating to chrome 33 it ran poorly.

    I tweaked the settings in chrome://flags (for a good hour -,-) but either they didnt seem to do anything, or actually made it worse

    Anything I can do/try similair to that short cut approach Arima did ?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)