843685 - Investigate using gralloc locking for b2g GL streaming textures

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Once we have the basic gralloc/IPC backend implemented in bug 843599, and the async canvas work from bug 829747, there will be one remaining issue with GL texture streams on B2G.

Currently, we have a no-op synchronous Flush() command to ensure that the compositor process has caught up to a certain point.  In ASCII art, this looks like:

  (First two frames are initialization/startup)
  Draw to buffer A
  Send buffer A

  Draw to buffer B
  Send buffer B

  Draw to buffer C
  Flush()
   -- when Flush() returns, we know that the compositor
   -- is done with buffer A, and we can re-use it (make
   -- it the new front buffer for WebGL)
  Send buffer C

  Draw to buffer A
  Flush()
   -- now we know that buffer B is done, use it as the
   -- front buffer
  Send buffer A

  Draw to buffer B
  Flush()
   -- new front buffer is now C after Flush returns
  Send buffer B

This works, but the Flush() means that content still has to wait for the compositor thread.  Instead, what we'd really like is to take advantage of some cross-process synchronization and locking, so that this looks like:

Lock A for Writing
Draw to A
Unlock A (W)
Send A
                       Compositor: Lock A for Reading as soon as it's received

Lock B for Writing
Draw to B              Compositor: currently rendering from A (with R lock held)
Unlock B (W)
Send B
                       Compositor: Lock B for Reading as soon as it's received
                       Compositor: Once rendering hits B, unlock A

Lock C for Writing
Draw to C              Compositor: currently rendering from B (with R lock held)
Unlock C (W)
Send C
                       Compositor: Lock B for R as soon as it's received

Try to lock A for Writing
--- main thread blocks until compositor is done reading from A;
--- if this does actually block, then it's ok, because we need to slow
--- down rendering.  We can do smart things like decrease rAF rate, but
--- initially just blocking is fine.
Draw to A
Unlock A (W)
....

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(Note: there is an alternate approach that doesn't require gralloc locking -- basically having the compositor send back async messages to the content process when the buffer transitions happen -- e.g. telling content that it's done with A, done with B, etc. and having content wait until those happen.  That might be useful on other places other than B2G too, but it's potentially more work... or maybe less, since it's all under our control.)

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.