On 2018-02-02 10:42 AM, Roman Gilg wrote: > It's because of what you made me aware of in the previous patch set: > the window original pixmap needs to have the updated content from the > flip Pixmap, otherwise for example screenshot applications won't work > anymore. I tested it with xwd.
FWIW, my concerns were about using sub-surfaces in cases where the presented pixmap dimensions don't match the window pixmap dimensions. > I also tried to not copy, but set the window pixmap to the flip > pixmap. The problem I encountered here, is that the window original > pixmap can be controlled by the client. How? > And when unflipping and restoring the original pixmap, this already > might have been deleted by the client. A pixmap is only destroyed when its refcnt member drops to 0, so that shouldn't be an issue. > There might be ways to circumvent this problem, I have a few ideas, > but I decided to first go for a simple implementation by just copying > the pixmap content in order to decrease the overall complexity of the > patch set. I'm not sure it would significantly increase the complexity, but fair enough I guess. The inability to queue a presentation to the next MSC is more of a step back compared to the status quo. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ firstname.lastname@example.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel