screenshotting, screencasting & unity8+mir

Alexandros Frantzis alexandros.frantzis at canonical.com
Tue Nov 26 15:12:37 UTC 2013


On Tue, Nov 26, 2013 at 01:13:28PM +0000, Gerry Boland wrote:
> Hey,
> The system compositor will probably not be using the Qt scenegraph, but
> instead Mir's own compositor. I don't know if using
> QQuickWindow::grabWindow() will work in that case (though if it just
> calls glReadPixels, it probably will).
> 
> Also if hardware (non-GL) compositing is being used, reading back pixels
> via glReadPixels won't be enough as not everything on screen will be
> drawn by GL.
>
> As a result, I'm not certain we can rely on QQuickWindow::grabWindow() /
> glReadPixels, but would need something internal to Mir.
>

In general, graphics cards and drivers don't offer access to the final
output buffer (after HW compositing), at least not through a standard
API (I don't know if Android drivers offer such functionality). Even if
we move the screenshoting functionality into Mir, it's probable that the
best we will be able to do is to recomposite everything using OpenGL and
read back the pixels.

Perhaps what could happen is that when Unity8 wants to take a screenshot
it can tell Mir to composite everything with OpenGL for the current
frame.

The original discussion was about autopilot being able to take
screenshots/casts of unity8 for testing and validation purposes, and we
came up with a simple solution for this use case.

However, it seems that people have more use cases for screen capturing
that require additional complexity. I think we need to discuss a bit
more about what we really need and when, check what is feasible in our
time frames and prioritize work. The upcoming sprint seems ideal for
this.

Thanks,
Alexandros



More information about the Mir-devel mailing list