Screencasting is GL renderer-specific

[Daniel van Vugt]

Screencasting is GL renderer-specific

This creates two problems:
  1. Writing a screencast/screenshot client is unreasonably difficult.
  2. Such a client is also GL-specific.

Ideally our renderers should just be aware of when there is a client wanting a cast, and each renderer should be able to scrape its own screen and export that to a software buffer. Thus screencasting clients would never need to use GL. This would also solve bug 1660266 and possibly bug 1294362.

[Kevin DuBois (kdub)]

I agree that GL is too entrenched in the screencast code at the current time. Part of the renderer work should be to be able to replace the screencast bits easily.

However, I'm not quite sure its reasonable for clients to render to screen with GL and render to the screencast using another method. Translating GL state to another method would be quite burdensome for anyone wanting to draw via GL.

[Daniel van Vugt (vanvugt)]

I think this is pretty simple in theory. Using desktop GL you could just read the back/front buffers. Using ES you can't do that, but you can render every frame to an FBO and then to the screen. And I believe GLES is happy to read pixels from an FBO (that's how our current casting works).

So really the FBO approach just needs to be merged into the GL renderer. Then it will be capable of reading its own output and providing a software buffer of the latest frame, and many other potentially fun things.

[Daniel van Vugt (vanvugt)]

Interestingly, screencasting via linear buffers also lets you select a specific window for casting. That is at screen address (FBO_stride * window_y + window_x), and has stride (window_stride).

[Daniel van Vugt (vanvugt)]

Correction:
That is at screen address (FBO_stride * window_y + window_x), and has stride (FBO_stride), but still window_width and window_height.

[Michał Sawicz (saviq)]

Syncing task from Mir.