screenshotting, screencasting & unity8+mir

[Thomi Richards]

Hi Kevin,


Thanks for the summary.

Might I be a pain, and suggest that if it's going to happen through the mir
API, we also need a simple app that can take screenshots. Writing python
<-> C bindings probably isn't the best way to go here, so I wonder if we
could have a simple app that we can call like so: "mir-screenshot
/path/to/file.png".

That should be easy to write, I think?


On Thu, Dec 5, 2013 at 12:33 AM, Kevin Gunn <kevin.gunn at canonical.com>wrote:

> After some discussion
>
>    - first goal is to satisfy our QA requirement to capture full screen
>    output
>       - note, fullscreen only for now, not going to address app windows
>    - screencast/screenshot will go through the mir api
>       - e.g. mir_connection_output_surface, where the client can indicate
>       whether or not the client wants a gl or sw buffer, and then
>       mir_output_advance_buffer to indicate reading the next buffer (note names
>       subj to change...just proposed ;)
>       - which fails for unprivileged clients
>       - we did discuss the potential addition of explicit capability
>       acquire/release for privileged apps, but it was decided we shouldn't add
>       this to the api until we have more concrete need/use cases
>    - mir will have a server side check with unity-mir for unity8 to check
>    against app armor to determine if the app has the capability to screencast,
>    this check will only happen when the call to the api is made
>
>
>
>
> On Thu, Nov 28, 2013 at 1:40 AM, Daniel van Vugt <
> daniel.van.vugt at canonical.com> wrote:
>
>> 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
>>>
>>>
>>>
>> --
>> Mir-devel mailing list
>> Mir-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/mir-devel
>>
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>


-- 
Thomi Richards
thomi.richards at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131206/fbe3803d/attachment.html>