WebGL not what it is cracked up to be?

0 favourites
  • 11 posts
  • Just some observations regarding WebGL.

    I was doing an update for our Steve Storm and the Tables of Doom (https://www.scirra.com/forum/viewtopic.php?f=148&t=87022&p=693213&hilit=tables+of+doom#p693213) project. I decided to set it to use WebGL. With the changes to CocoonJS I figured it would be worth trying.

    I exported the resulting ZIP file and opened it in the CocoonJS Launch app of my iPad 3 (1st with retina display).

    I noticed the FPS weren't great and going into one of the layouts it dropped to 10 FPS. I also noticed strange graphic artefacts, the seamless tiled background now had faint lines around each "square".

    I retried the app after exporting with WebGL switched off in the project. The Layour now ran at 37FPS and the weird lines were no longer visible.

    This is not what I expected. I was under the impression that WebGL would accelerate my app and provide much better performance. However, in this case the opposite was true.

    Anyway, I thought I would put it out there as experience.

  • Are you sure you have WebGl on your iPad? - Setting it to ON in C2 doesn't always mean you will get it on end device. Try to add simple text or something to show if your device is using WebGl or is it still canvas2d - Had similar issue with crosswalk and samsung galaxy s3.

  • iPad/iOS does not support webGL.

  • Kyatric So why the difference in results?

    And I was under the impressions that cocoonjs was now using webgl on ipad

  • Kyatric So why the difference in results?

    And I was under the impressions that cocoonjs was now using webgl on ipad

    WebGL, if not supported, can still be forced (maybe cocoonJS was doing that)

    In some cases it is fine, even better than having it disabled, but in other cases, you understand quickly why it is not enabled by default (graphical glitches, crashes, difficulties..).

  • Old read but still useful.

    So once again, iOS is not meant/designed to support webGL, so there is no actual drivers meant to directly "discuss" with the GPU the "webGL way".

    Why the difference then when you "force" webGL ? Likely because everything that is supposed to be calculated on the GPU's level is actually processed by the CPU.

    You can't force what isn't supported. We're not talking about magic here, we're talking technology and software implementation.

    It's not implemented so it can't work, simple and logical as that. Stop dreaming guys...

  • Gawdamn Apple is all I can say...

  • I think there is a lot of confusion about what is really CocoonJs .

    CocoonJS (Canvas+) is not a browser, it's a wrapper that mimics a browser intercepting draw calls and "converting" them to OpenGL ES calls so you can't expect the same behaviors that you can see using a real browser.

    "WebGL is faster than Canvas2d" is a true statement only when there's a real browser involved but since WebGL is not supported by iOs what we see on our iphones screen is an "emulation".

    Ashley said once that WebGL engine is a little slower due to technical reasons on javascript execution side and a lot faster at drawing things on screen. So, in the end, you have an huge performance improvement. But this happens only on real browsers.

    We don't know how CocoonJS works behind the scene but we know that the iOS SDK agreement requires apps to use Apple's own JavaScript engine which is a lot slower than modern JS engines.

    My speculation is that since maybe CocoonJS accelerates in the same manner both Canvas2d and WebGL calls, the gap you see in favour of Canvas2d is related to the slow and old JS engine that apple imposes on their developers.

  • Knifegrinder thanks for the interesting response.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • CocoonJS does support WebGL, but iOS does not support JIT compilation for Javascript, so JS execution speed is slower. On most platforms WebGL is a lot faster since it moves more of the renderer code in to our own highly-optimised Javascript implementation and minimises expensive Javascript-to-native context switches, but since iOS does not compile JS this runs slower and seems to be approximately the same performance (although results for specific games may vary). Also IDK if CocoonJS has bugs that cause artefacts in its WebGL implementation, the best way to check would be to run in a real browser with WebGL support.

    In short in real browsers WebGL is very much a good thing, but in CocoonJS which only pretends to be a browser, and iOS apps which don't allow fast Javascript, it can be more hit and miss.

  • Ashley thanks for the detailed response, that clears it up

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