screenshotting, screencasting & unity8+mir

[Thomas Voß]

On Wed, Nov 27, 2013 at 2:38 AM, Daniel van Vugt
<daniel.van.vugt at canonical.com> wrote:
> On an implementation note...
>
> I think adding yet more library dependencies (dbus) to Mir would be a
> mistake. It's already quite bloated in that respect.
>

+1, Mir should expose the required functionality via its server-side interfaces.
Exposure to other clients than the shell is then the responsibility of
the shell from my pov.

  Thomas

> The key recording functionality in Mir shouldn't care about the
> communications anyway. So it would probably be a cleaner division of
> responsibility to make the bus communication external to libmir*. Either
> attached to unity-mir or some privileged client etc.
>
>
>
> On 26/11/13 20:31, Daniel d'Andrada wrote:
>>
>> Hi,
>>
>> On November 26th I (Unity8), Kevin Gunn, Chris Gagnon (Autopilot) and
>> Alexandros Frantzis (Mir) had a meeting on the requirements and
>> implementation of screenshotting and screencasting.
>>
>> Chris told us that what autopilot really wants is screencasting (not
>> screen shots) as it records all that happens during a test case and
>> publishes the resulting video in case of failure.
>>
>> Kevin came with the point that application developers already want
>> screenshotting and screencasting and therefore the solution should also
>> cater to them (as opposed to having a solution that works for autopilot
>> now and for other/third-party applications to be done only later).
>>
>> Thus considering those requirements and the future mir architecture
>> (using qt scenegraph), that's the implementation we agreed upon:
>>
>> Unity8 would provide a D-Bus service for clients (applications,
>> autopilot) to request for a screencast or screenshot. In case of a
>> screenshot, the requestor would just provide a filename (or directory)
>> where the screenshot(s) should be placed and unity8 would do it. For
>> screencasts unity8 would provide a shared memory area to the requestor
>> that would be kept up to date with the contents of the screen. Access to
>> that shared memory area would be controlled with a semaphore and a
>> mutex. So the problem of handling codecs, recording and audio stream to
>> go along with it, etc is left to the user (i.e. an actual screencasting
>> application or tool).
>>
>> D-Bus was chosen because access control to the screenshot/screencast
>> feature can be easily implemented using D-Bus security policies.
>> According to Alexandros, Mir probably won't have to be modified for
>> screen[shotting|casting]. As a QQuickWindow will be controlling the
>> composition now (qt-scenegraph approach), what would have to be done is
>> calling glReadPixels right after the scene graph is rendered, which is
>> essentially how "QImage QQuickWindow::grabWindow()" is implemented (if I
>> understood its code correctly).
>>
>> So that's where I'm heading with the implementation (didn't start yet).
>> If someone has a better idea, sees a problem with this approach or
>> otherwise has something to add, please advise.
>>
>> Feedback already received so far:
>>
>> Thomi Richards:
>>   - Clarified that autopilot also wants screenshots.
>>   - Asked for a command line tool that does all the work of talking to
>> that proposed screencasting API and outputs an ogv.
>>
>> Michał Sawicz:
>>   - "I'm not sold on the idea that it's unity8's / unity-mir's
>> responsibility to provide that interface, though, as the ability to do
>> those feels like a very generic need that should be built into the
>> display server itself. Maybe the fact that we might be using Qt's
>> scenegraph changes something here, though - but maybe that just means
>> there's a new project growing on unity-mir's side?"
>>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel