5 ms·

You probably don't have GPU acceleration enabled/supported in your browser. For example, if you use Chrome, check about:gpu.

jablan 12y ago
That's true (thanks), but anyways, it seems to me that a simple animation should take only a fraction of a modern CPU's (or GPU) power. Is the engine calculating more often than what's needed for 60fps or whatever refresh rate our eyes need to be satisfied?
- shakiba 12y ago
  The issue is not with this engine, no other HTML5 game/engine can do better in your browser. CPU is not optimized to do what takes only a fraction of GPU.
  - kevingadd 12y ago
    This is false. Properly optimized rasterizers (like Adobe Flash's, for example) can deliver vastly superior performance for simple animated scenes like that, and have been doing so for over a decade. Cut's renderer would be much faster if it were designed in a GPU and CPU-friendly manner instead of the naive graph traversal it does right now (I'll post about this in detail outside this thread)
    - shakiba 12y ago
      CutJS is already GPU and CPU-friendly, the problem is that his browser is not GPU-enabled and uses CPU for GPU tasks. It is not about CutJS, Canvas or Flash. When you use CutJS with a GPU enabled browser only a very small portion of CPU is used which shows that is CPU-friendly.
      - kevingadd 12y ago
        As I mention in my top level post, this is false. The most obvious example is that you do all your rendering and updates in graph traversal order, even though this is one of the worst traversal orders to use because it minimizes the effectiveness of the processor's caches and produces the maximum number of GPU state changes. GPU state changes increase both CPU and GPU overhead, and in a software rasterizer they also prohibit efficient caching (for example, in Cairo). You can say it's efficient as much as you like, but you clearly haven't done much research if you think it's fast just because the CPU usage is low in your trivial demos - demos that cause GC pauses on a regular basis, I should note. If you want to claim that it's fast and GPU/CPU friendly, you should be profiling it in a GPU profiler like PIX to ensure that it produces few GPU draw calls and state changes, and profiling it in a CPU profiler to ensure that virtually all the time spent is spent inside of the Canvas implementation - which, sadly, is not true for your example game 'O!' in the Chrome Profiler.

jablan 12y ago

That's true (thanks), but anyways, it seems to me that a simple animation should take only a fraction of a modern CPU's (or GPU) power. Is the engine calculating more often than what's needed for 60fps or whatever refresh rate our eyes need to be satisfied?

shakiba 12y ago
The issue is not with this engine, no other HTML5 game/engine can do better in your browser. CPU is not optimized to do what takes only a fraction of GPU.
- kevingadd 12y ago
  This is false. Properly optimized rasterizers (like Adobe Flash's, for example) can deliver vastly superior performance for simple animated scenes like that, and have been doing so for over a decade. Cut's renderer would be much faster if it were designed in a GPU and CPU-friendly manner instead of the naive graph traversal it does right now (I'll post about this in detail outside this thread)
  - shakiba 12y ago
    CutJS is already GPU and CPU-friendly, the problem is that his browser is not GPU-enabled and uses CPU for GPU tasks. It is not about CutJS, Canvas or Flash. When you use CutJS with a GPU enabled browser only a very small portion of CPU is used which shows that is CPU-friendly.
    - kevingadd 12y ago
      As I mention in my top level post, this is false. The most obvious example is that you do all your rendering and updates in graph traversal order, even though this is one of the worst traversal orders to use because it minimizes the effectiveness of the processor's caches and produces the maximum number of GPU state changes. GPU state changes increase both CPU and GPU overhead, and in a software rasterizer they also prohibit efficient caching (for example, in Cairo). You can say it's efficient as much as you like, but you clearly haven't done much research if you think it's fast just because the CPU usage is low in your trivial demos - demos that cause GC pauses on a regular basis, I should note. If you want to claim that it's fast and GPU/CPU friendly, you should be profiling it in a GPU profiler like PIX to ensure that it produces few GPU draw calls and state changes, and profiling it in a CPU profiler to ensure that virtually all the time spent is spent inside of the Canvas implementation - which, sadly, is not true for your example game 'O!' in the Chrome Profiler.