3 ms·

It performs poorly in either case. For one, Javascript APIs have significant marshalling overhead. Secondly, Canvas is often "hardware-accelerated", which can

It performs poorly in either case. For one, Javascript APIs have significant marshalling overhead. Secondly, Canvas is often "hardware-accelerated", which can make some things faster, but also slower because this kind of immediate-mode drawing doesn't match the GPU interface well. It's particularly slow at vector graphics. Some effects would require pixel readback, which is slow for the same reason. > Personally, I would be happy if Canvas just let you put raw pixel data on the screen and did that as well as possible. Drawing cached Bitmaps is relatively fast in Canvas, if you don't need too many calls. Getting arbitrary data into such a Bitmap is slow, so if you want to do it every frame you may run into issues.

kllrnohj 5y ago
> Secondly, Canvas is often "hardware-accelerated", which can make some things faster, but also slower because this kind of immediate-mode drawing doesn't match the GPU interface well. It's particularly slow at vector graphics. Some effects would require pixel readback, which is slow for the same reason. https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE... One would assume/hope that specifying "bitmaprenderer" for the context type would give you a regular immediate-mode CPU rasterizer. Is that not the case? > Getting arbitrary data into such a Bitmap is slow, so if you want to do it every frame you may run into issues. To expand on this, doing that ("putting raw pixel data on screen") anywhere is slow if it's modified regularly. There just doesn't exist a fast CPU-buffer-to-display pipeline anymore, that died out years & years ago. So that one at least isn't a JS/web limitation, it's more a modern graphics architecture one. You just can't bit-bang pixels yourself anymore, not reasonably efficiently anyway. In theory that'd be possibly on unified memory architectures (read: mobile devices & integrated graphics), but GPUs don't like to publish their swizzled texture formats so you still don't get to even there.
- incrudible 5y ago
  > One would assume/hope that specifying "bitmaprenderer" for the context type would give you a regular immediate-mode CPU rasterizer. Is that not the case? No, that's something else. > To expand on this... I almost wrote something like that, but then I considered that I haven't really benchmarked this. Streaming data from CPU onto the GPU is certainly possible and graphics APIs do have hints for such usage. You also don't need to convert to a texture to get arbitrary data on the screen, a trivial shader can do that for you. If your data/transformations naturally live in RAM/CPU, that may well be the most efficient thing to do.

kllrnohj 5y ago

> Secondly, Canvas is often "hardware-accelerated", which can make some things faster, but also slower because this kind of immediate-mode drawing doesn't match the GPU interface well. It's particularly slow at vector graphics. Some effects would require pixel readback, which is slow for the same reason. https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE... One would assume/hope that specifying "bitmaprenderer" for the context type would give you a regular immediate-mode CPU rasterizer. Is that not the case? > Getting arbitrary data into such a Bitmap is slow, so if you want to do it every frame you may run into issues. To expand on this, doing that ("putting raw pixel data on screen") anywhere is slow if it's modified regularly. There just doesn't exist a fast CPU-buffer-to-display pipeline anymore, that died out years & years ago. So that one at least isn't a JS/web limitation, it's more a modern graphics architecture one. You just can't bit-bang pixels yourself anymore, not reasonably efficiently anyway. In theory that'd be possibly on unified memory architectures (read: mobile devices & integrated graphics), but GPUs don't like to publish their swizzled texture formats so you still don't get to even there.

incrudible 5y ago
> One would assume/hope that specifying "bitmaprenderer" for the context type would give you a regular immediate-mode CPU rasterizer. Is that not the case? No, that's something else. > To expand on this... I almost wrote something like that, but then I considered that I haven't really benchmarked this. Streaming data from CPU onto the GPU is certainly possible and graphics APIs do have hints for such usage. You also don't need to convert to a texture to get arbitrary data on the screen, a trivial shader can do that for you. If your data/transformations naturally live in RAM/CPU, that may well be the most efficient thing to do.