All users were logged out of Bugzilla on October 13th, 2018

consider falling back to image surfaces on getImageData

NEW
Unassigned

Status

()

8 years ago
4 years ago

People

(Reporter: vlad, Unassigned)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

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.

Comment 1

4 years ago
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.