screenshotting, screencasting & unity8+mir

[Daniel van Vugt]

Keeping in mind recording at full frame rate (or near) would solve both 
problems, I think we should have a single approach.

The key thing to remember is bandwidth. Only the buffer sharing logic 
used in client IPC has the bandwidth to cope with recording/screencasting.

Consider: 1920x1200 x 4bytesperpixel x 60FPS
--> 553 megabytes per second

Or even: 1366x768 x 4bytesperpixel x 30FPS
--> 126 megabytes per second

Hopefully it would be encoded more efficiently for storage, but still, 
you need to use buffer IPC that's designed for speed. Fortunately we 
have that already.


On 27/11/13 23:30, Ricardo Mendoza wrote:
> On Wed, 2013-11-27 at 07:32 +0100, Thomas Voß wrote:
>> 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.
>>>
>>> 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.
>
> Back to this, providing a screenshotting interface with a default file
> sink is a matter of... 30 minutes? I believe extending the
> com.canonical.Unity.Screen interface; as long as you decide on a place
> to put screenshot files and a default format.
>
> I believe we should provide this right away for QA, the rest of the plan
> seems more broad and therefore not really committable to a strict
> timeframe. I agree that casting would be great and that we need it, just
> not sure if its the right time to slot it into the dev plan.
>
>>> 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
>
> Regards,
>
>
>       Ricardo
>
>