screenshotting, screencasting & unity8+mir

Thomas Voß thomas.voss at canonical.com
Wed Nov 27 06:32:21 UTC 2013


On Tue, Nov 26, 2013 at 4:12 PM, Alexandros Frantzis
<alexandros.frantzis at canonical.com> wrote:
> 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.
>

That's a fair point. As I understand it, there is the immediate
requirement to support QA with screenshotting capabilities and the
presented approach can be used to provide the required functionality.

> 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.
>

+1.

Cheers,

  Thomas

> Thanks,
> Alexandros
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel



More information about the Mir-devel mailing list