Closed Bug 580781 Opened 11 years ago Closed 9 years ago

Efficiently share BasicImageLayer/BasicImage data with BasicShadowImageLayer

Categories

(Core :: Graphics, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cjones, Unassigned)

References

Details

With bug 570294, we grab the current image on Paint()s and then copy it to a shmem back buffer, which is then swapped with the old front buffer.  This is inefficient both in CPU and memory usage.  We need to make it better.

There are numerous ways to optimize this.  In the long run, we'll want to have the decoder thread publishing decoded data directly to the compositing process, bypassing the main thread.  In the interim when the main thread is still involved, we can still make this pipeline faster by decoding directly to shmem, e.g.  Thoughts from people who know this code would be appreciated.
Why don't we just implement the optimal solution?

Seems to me we should memcpy the image data into shared memory and on the compositor process side you can synchronously upload it to the GPU.
We need some IPC arch work to bypass the content-process main thread (specifically, open a new channel to the compositor); that's bug 564086.  To mitigate risk, I think we should first implement the already-supported route of decoding into shmem and publishing updates from the content-process main thread (then uploading to the GPU from compositor etc.).  I expect that to be easy, and it'll still be strictly better than fennec2.0a1 with shmem canvas.
This is definitely still the case, though I'm not clear on whether it's a huge issue. Making it possible to bypass the main thread depends on OMTC, which Ali and Benoit are working on.
Depends on: omtc
No longer depends on: omtc
Depends on: omtc
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.