Hacker News Reader

Comment by tomxor | Hacker News Reader

Note that OffscreenCanvas is currently only implemented in chromium based browsers [0]

It is a neat idea, basically separating all the canvas calls into a webworker so it can run on it's own thread. However this scale of parallelism is not a solution to fundamentally slow code... the map rendering performance is still poor, it's just been prevented from interfering with the main thread. Please don't throw web workers at stuff before asking why the code or API calls are slow first.

[0] https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa...

View on HN

Without off screen canvas and threading your UI and logic are all being done in a single thread, causing significant lag problems that every other kind of application has resolved since the 90's. Threading is am essential part of any user facing application, and browsers outside of chrome have continually squandered the ability to put out good quality UI that does intensive background work. Something as simple as a video player in wasm requires at least 1 other thread.

There's still a major disconnect in this blog post. The problem statement was making all web-enabled devices performant with Canvas, not just desktops and mobiles running Chrome. If Off Screen Canvas is only available for a recent version of one browser engine, it's not going to solve that problem is it?

The core map code is slow, why doesn’t the map code optimize its runtime by using threads? Then the main thread canvas just renders the current state? That’s how you solve the problem, not by creating an entire new canvas to solve the crappy map code. You’re right, people have solved these problems with threads, but on a much better way. Google needs to stop reinventing the wheel and fix their problems.

Sure,but don't underestimate the better user interactivity. The ability tô interact during the rendering is a HUGE usability improvment.

The GP meant that a fundamentally slow code can't be made faster that much. Offloading canvas calls without making the rendering itself faster can easily mask the performance issue, which is very relevant (and frequently ignored) in mobiles.

There are definitely legitimate use cases, like rendering text tiles in parallel workers and letting the main thread blit them all together. Text rendering is one of the slowest canvas drawing operations, and blitting is super fast, so this can make a huge difference in responsiveness if you’re zooming or scrolling.

Reply on news.ycombinator.com