Open Bug 625267 Opened 13 years ago Updated 3 months ago
consider falling back to image surfaces on get
getImageData is a speed trap when we're using hw accel surfaces, especially with D2D. bz suggested that we consider falling back to a gfxImageSurface if we hit getImageData/putImageData. Perhaps a smarter heuristic can allow us to shuffle surfaces back and forth as needed -- we may even be able to map the hw surface into memory for a period of time.
As I understand it from reading other bugs the major issue is waiting for the surface to be read from the gfx memory. Would it be possible to this off-thread and get the image data asynchronously? I'm guessing this is more of an interleaving/latency issue (GPU and CPU taking turns to wait on each other) than a bandwidth bottleneck. I know a new API would be necessary for this, but other browsers seem to have the same issue, so it might be useful as a standard. Depending on the exact use-cases that might be sufficient to allowing developers to simply prepare multiple frames in advance and/or do other work while waiting on the readback. Same could apply to writes, except that they don't even need a callback, they could just be put on a queue and worked off in the background. This is mostly interesting for off-window surfaces that are used for pixel data twiddling where high throughput and some degree of parallelism is more desirable than jank-free, frame-accurate rendering. Although one can serve as precomputation for the other.
You need to log in before you can comment on or make changes to this bug.