5 ms·

This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyon

This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyone know if there could be a WebGL optimization issue?

TrevorSundberg 3y ago
It almost sounds like it’s not using your dedicated graphics card. Do other WebGL demos run alright for you?
- sansseriff 3y ago
  Yes I can run about 200 jellyfish in this demo with similar GPU load, resolution, and frame rate. https://akirodic.com/p/jellyfish/ https://akirodic.com/p/jellyfish/ Maybe not the most helpful comparison haha. Anyways, great work, this is very impressive
  - h4zel 3y ago
    Same experience here. I'm able to run other webgl projects fine, including the jellyfish project you linked, but this engine blows up my gpu. Strange
  - Narishma 3y ago
    That's WebGL. This engine seems to use WebGL2.
a_JIT_pie 3y ago
I'm getting a really nice smooth experience on my Intel HD Graphics 620 (7th gen intel integrated graphics, old and slow). Also just looking at the default ball scene, and I was really impressed how smooth it was on my system. I'm using chrome.
- meheleventyone 3y ago
  I suspect this is possibly down to the use of readPixels and how slow that is on various devices. The engine seems to run in a worker and render to an offscreen canvas then transfer the image data in JS to the main thread before drawing it to a canvas there.
  - TrevorSundberg 3y ago
    The transfer of image data only happens when we yield inside the engine which only occurs when you hit a breakpoint in script. Otherwise we're just rendering to the OffscreenCanvas and letting the normal flow blit it to the screen (not doing any copying). I just did some profiling on Firefox and I feel like the profiling result doesn't quite make sense but it's saying that the majority of time is spent calling Performance.now() from the clock calls in C++. I'm wondering if that's because we're calling it too many times and maybe we should just call it once per frame.
    - meheleventyone 3y ago
      FWIW my poor performance is in Chrome on Apple Silicon not Firefox.
TrevorSundberg 3y ago
Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/

TrevorSundberg 3y ago

It almost sounds like it’s not using your dedicated graphics card. Do other WebGL demos run alright for you?

sansseriff 3y ago
Yes I can run about 200 jellyfish in this demo with similar GPU load, resolution, and frame rate. https://akirodic.com/p/jellyfish/ https://akirodic.com/p/jellyfish/ Maybe not the most helpful comparison haha. Anyways, great work, this is very impressive
- h4zel 3y ago
  Same experience here. I'm able to run other webgl projects fine, including the jellyfish project you linked, but this engine blows up my gpu. Strange
- Narishma 3y ago
  That's WebGL. This engine seems to use WebGL2.

a_JIT_pie 3y ago

I'm getting a really nice smooth experience on my Intel HD Graphics 620 (7th gen intel integrated graphics, old and slow). Also just looking at the default ball scene, and I was really impressed how smooth it was on my system. I'm using chrome.

meheleventyone 3y ago
I suspect this is possibly down to the use of readPixels and how slow that is on various devices. The engine seems to run in a worker and render to an offscreen canvas then transfer the image data in JS to the main thread before drawing it to a canvas there.
- TrevorSundberg 3y ago
  The transfer of image data only happens when we yield inside the engine which only occurs when you hit a breakpoint in script. Otherwise we're just rendering to the OffscreenCanvas and letting the normal flow blit it to the screen (not doing any copying). I just did some profiling on Firefox and I feel like the profiling result doesn't quite make sense but it's saying that the majority of time is spent calling Performance.now() from the clock calls in C++. I'm wondering if that's because we're calling it too many times and maybe we should just call it once per frame.
  - meheleventyone 3y ago
    FWIW my poor performance is in Chrome on Apple Silicon not Firefox.

TrevorSundberg 3y ago

Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/ https://raverie-us.github.io/raverie-engine/