580781 - Efficiently share BasicImageLayer/BasicImage data with BasicShadowImageLayer

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 3

[Joe Drew (not getting mail)]

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.