Us: 2D Canvas toDataURL Completed successfully 603.39ms Chrome: 2D Canvas toDataURL Completed successfully 273.30ms

I didn't poke at this hard, but it looked like we were spending a lot of time in D2D calls.

Paging Bas!

We'll be doing a lot of readback from the GPU. We may need to detect heavy use of getImageData and toDataURL and migrate such canvases off the GPU.

It might be nice to just add an attribute to keep canvas's off the GPU. I know Apple was opposed to it, but I think Google would like the idea.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4) > It might be nice to just add an attribute to keep canvas's off the GPU. I > know Apple was opposed to it, but I think Google would like the idea. I agree with the idea of having a flag that says 'fast readback' or something.

I also wonder how much value would be gained by making getImageData()/toDataURL() semi-asynchronous. i.e. We start the process of getting the data back from the GPU when getImageData is called but don't block on it until we need it.

You could do that for getImageData, sure. toDataURL would be harder without some sort of magical string promise type thing.

You also have to block once somebody tried to modify the canvas, of course.

I'd rather ask why we care -- sure, google presentations wants toDataURL to be faster, but I have to assume that they want it for a one-time shot (in which case the repeated calls that this is doing aren't relevant), or perhaps for a use case that we should be doing something better for (e.g. if they want to display a thumbnail of the current slide, we should support something like <svg:foreignObject ref="#otherItem"/>).

Wes reminded me that we already have -moz-element() that does exactly this!

It's tempting to introduce a custom [Pure] WebIDL attribute and have the JS compiler throw away calls to pure methods whose results are not used. Alternatively, allow WebIDL to bind two versions of a method: one where the result is used, and one where it is not. Then we could have optimized implementations of methods whose results are not used. What's our goal here anyway? To win the benchmark? To improve performance of the application that inspired this benchmark?

The latter goal seems reasonable to me. I think we should be willing to challenge the benchmark itself as needed if it's not representative of the app that inspired it.

The problem is we don't know what the behavior of the application is. Does it actually request the toDataURL of an unchanged document over and over again? Does it make small changes to the same canvas repeatedly, taking toDataURL each time? Does it always call toDataURL on a canvas just once and then switch to a new canvas? etc.

Sure. We should file bugs on robohornet to answer these questions. I filed https://github.com/robohornet/robohornet/issues/73 To be clear, this bug was filed because this was one of the places we had a large discrepancy vs Chrome, not because I think this is an important benchmark per se.