4 ms·

canvas { display: none !important; }

by ugh 15y ago

bzbarsky 15y ago
This doesn't help that much, almost certainly. It prevents having to recomposite the canvas to the page, but the drawing to the canvas still has to happen....
- ugh 15y ago
  I would very much hope that browsers don't implement canvas that way. Surely no one can be that stupid?
  - halter73 15y ago
    What if the following line is executed after the hidden canvas's context has been modified? canvasElement.setAttribute('style', 'display:inline !important'); According to you, non-stupid browsers should have ignored the previous updates to the canvas to save CPU time. Maybe the browser could keep a record of all of the calls made to the canvas API while the canvas is hidden and then execute them when the canvas element becomes unhidden, but that seems clever to me. I certainly wouldn't call implementors of the canvas API that don't do this stupid. In fact, there are probably good reasons not to do this. For example, if a web app makes frequent updates to a small hidden canvas, keeping a record of all the calls instead of simply executing them could end up using way too much memory. If a browser simply ignores updates to the hidden canvas, it would be breaking standards.
  - bzbarsky 15y ago
    You pretty much have to implement it that way. Not only because the canvas can later be shown, as halter73 points out, but also because of the getImageData API, which allows one to extract the pixel data from a canvas that's not being shown any time you feel like it. Also, a hidden canvas can be drawn to other canvases via drawImage, can be serialized to a data: URI at any time and so forth. So you really do need to be able to produce the right pixel data on demand. That means either doing the drawing when told to draw or buffering up the drawing commands (which can get pretty complicated, because some of them depend on the style of the canvas at the time the draw happened, so you either have to cache a bunch of style information or flush the drawing command buffer when style information changes or ... something). And as halter73 points out, it's very easy to end up with an effective memory leak when doing this sort of buffering.

canvas { display: none !important; }

by ugh 15y ago

canvas { display: none !important; }

This doesn't help that much, almost certainly. It prevents having to recomposite the canvas to the page, but the drawing to the canvas still has to happen....

ugh 15y ago
I would very much hope that browsers don't implement canvas that way. Surely no one can be that stupid?
- halter73 15y ago
  What if the following line is executed after the hidden canvas's context has been modified? canvasElement.setAttribute('style', 'display:inline !important'); According to you, non-stupid browsers should have ignored the previous updates to the canvas to save CPU time. Maybe the browser could keep a record of all of the calls made to the canvas API while the canvas is hidden and then execute them when the canvas element becomes unhidden, but that seems clever to me. I certainly wouldn't call implementors of the canvas API that don't do this stupid. In fact, there are probably good reasons not to do this. For example, if a web app makes frequent updates to a small hidden canvas, keeping a record of all the calls instead of simply executing them could end up using way too much memory. If a browser simply ignores updates to the hidden canvas, it would be breaking standards.
- bzbarsky 15y ago
  You pretty much have to implement it that way. Not only because the canvas can later be shown, as halter73 points out, but also because of the getImageData API, which allows one to extract the pixel data from a canvas that's not being shown any time you feel like it. Also, a hidden canvas can be drawn to other canvases via drawImage, can be serialized to a data: URI at any time and so forth. So you really do need to be able to produce the right pixel data on demand. That means either doing the drawing when told to draw or buffering up the drawing commands (which can get pretty complicated, because some of them depend on the style of the canvas at the time the draw happened, so you either have to cache a bunch of style information or flush the drawing command buffer when style information changes or ... something). And as halter73 points out, it's very easy to end up with an effective memory leak when doing this sort of buffering.