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. > > As a result, I'm not certain we can rely on QQuickWindow::grabWindow() / > glReadPixels, but would need something internal to Mir. >
In general, graphics cards and drivers don't offer access to the final output buffer (after HW compositing), at least not through a standard API (I don't know if Android drivers offer such functionality). Even if we move the screenshoting functionality into Mir, it's probable that the best we will be able to do is to recomposite everything using OpenGL and read back the pixels. Perhaps what could happen is that when Unity8 wants to take a screenshot it can tell Mir to composite everything with OpenGL for the current frame. 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. 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. Thanks, Alexandros -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
