<div dir="ltr"><div>After some discussion</div><div><ul><li>first goal is to satisfy our QA requirement to capture full screen output</li><ul><li>note, fullscreen only for now, not going to address app windows</li></ul><li> screencast/screenshot will go through the mir api</li><ul><li>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 ;)</li> <li>which fails for unprivileged clients</li><li>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</li> </ul><li>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</li></ul> </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Nov 28, 2013 at 1:40 AM, Daniel van Vugt <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div class="HOEnZb"><div class="h5"> On 27/11/13 23:30, Ricardo Mendoza wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, 2013-11-27 at 07:32 +0100, Thomas Voß wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, Nov 26, 2013 at 4:12 PM, Alexandros Frantzis <<a href="mailto:alexandros.frantzis@canonical.com" target="_blank">alexandros.frantzis@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, Nov 26, 2013 at 01:13:28PM +0000, Gerry Boland wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> 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. </blockquote> 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. </blockquote> 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. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> +1. Cheers, Thomas <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks, Alexandros </blockquote></blockquote> Regards, Ricardo </blockquote> -- Mir-devel mailing list <a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a> </div></div></blockquote></div> </div>