11 ms·

> The difference is night and day, 5000% and up for simple things like drawing. I find that seriously doubtful, you're going to have to provide a citation if y

> The difference is night and day, 5000% and up for simple things like drawing. I find that seriously doubtful, you're going to have to provide a citation if you want me to swallow that. The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls. If the difference is 5000% or more I will donate $20 to the charity of your choice.

GuiA 10y ago
> The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls. ...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
- SomeCallMeTim 10y ago
  Actually their example of iterating over an array and making WebGL calls is very close to exactly what you need to benchmark.
  - candiodari 10y ago
    It would seem more to the point for me to compare something like a game downloaded from steam with a webpage, as that is directly comparing the user experience. If you artificially limit the scope to something trivial, anything can work. I mean, that might be interesting for web browser developers, sure, and by all means, use it for that. But what matters is what experiences can be created by it. The web experience for games sucks.
- pcwalton 10y ago
  > That would be like benchmarking a language by seeing how fast it can add up integers. So you mean like most language benchmarks. :)
Game_Ender 10y ago
WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs. 0 - http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html

GuiA 10y ago

> The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls. ...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.

SomeCallMeTim 10y ago
Actually their example of iterating over an array and making WebGL calls is very close to exactly what you need to benchmark.
- candiodari 10y ago
  It would seem more to the point for me to compare something like a game downloaded from steam with a webpage, as that is directly comparing the user experience. If you artificially limit the scope to something trivial, anything can work. I mean, that might be interesting for web browser developers, sure, and by all means, use it for that. But what matters is what experiences can be created by it. The web experience for games sucks.
pcwalton 10y ago
> That would be like benchmarking a language by seeing how fast it can add up integers. So you mean like most language benchmarks. :)

Game_Ender 10y ago

WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs. 0 - http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html