nothing about graphics that necessitates "performance" above all else.
Brzzt, wrong.
Computers are, at the end of the day, meant for crunching numbers. Graphics is perhaps one of the last pure workloads that is about crunching numbers--it's probably the best match of the advances of the last 20 years to a problem domain we could hope for.
If your code cannot quickly do graphics, you have failed to competently make use of the user's resources. You are bad and are wasting their time and power, and in the one place where that inefficiency isn't justifiable.
> We're not all making AAA games.
Sure but we're also not all running MacBook Pros or GTX1080 cards on Xeons, now are we?
There's this mindset that high-performance graphics somehow only benefits gamers and games, and that's wrong.
Especially in the (mostly single-threaded, highly-marshalled) graphics environment of the browser, it is really easy to write code that will choke older machines to death and murder mobile devices.
This can be done with a large chart dataset, a quickly updating visualization, or any number of other reasonable and normal and non-game use cases.
>If your code cannot quickly do graphics, you have failed to competently make use of the user's resources. You are bad and are wasting their time and power, and in the one place where that inefficiency isn't justifiable
Bzzt wrong. Nobody cares much about efficiency above a certain level. If they did we wouldn't be using your "efficient" canvas, where 30% of calls is JS overhead, but native code.
>Sure but we're also not all running MacBook Pros or GTX1080 cards on Xeons, now are we?
No, but we almost all are running multi-core PCs, laptops and phones that are perfectly capable to run SVG for most things people use it for.
Maybe not plots with 10.000 points, but then again those are just badly designed, the screen doesn't have 10.000 pixels horizontally or vertically to show them all at once anyway.
> Nobody cares much about efficiency above a certain level
This line of thinking is why web mobile experience is garbage.
> Maybe not plots with 10.000 points, but then again those are just badly designed, the screen doesn't have 10.000 pixels horizontally or vertically to show them all at once anyway.
300x300 scatterplot holds potentially 90K points. Even in the case of just 10K datapoints, sampling considerations may mean that it is simpler and more maintainable to just ship full-resolution data to the frontend to be drawn--an option that only exists if you can do so efficiently.
Brzzt, wrong.
Computers are, at the end of the day, meant for crunching numbers. Graphics is perhaps one of the last pure workloads that is about crunching numbers--it's probably the best match of the advances of the last 20 years to a problem domain we could hope for.
If your code cannot quickly do graphics, you have failed to competently make use of the user's resources. You are bad and are wasting their time and power, and in the one place where that inefficiency isn't justifiable.
> We're not all making AAA games.
Sure but we're also not all running MacBook Pros or GTX1080 cards on Xeons, now are we?
There's this mindset that high-performance graphics somehow only benefits gamers and games, and that's wrong.
Especially in the (mostly single-threaded, highly-marshalled) graphics environment of the browser, it is really easy to write code that will choke older machines to death and murder mobile devices.
This can be done with a large chart dataset, a quickly updating visualization, or any number of other reasonable and normal and non-game use cases.