screenshotting, screencasting & unity8+mir

[Kevin Gunn]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131204/f5452d4f/attachment.html>