On December 28th, 2012, 3:17 p.m., Martin Gräßlin wrote:

completely unrelated comment to the patch: we need to think about a way to pass the screenshot to KSnapshot for Qt 5 as we cannot get a QPixmap from an X11 Pixmap any more.

/tmp/hash.png, shm or xputimage.

the absence of the native graphicssystem is gonna get us much more fun (current legacy decos, laptop happily segfaulted the x11 server on the raster engine here; xrender backend and raster decos are unusably slooow - so either we scratch that backend or figure a more general solution; painting some elements on xrender, we'll have to cache them in persistent Pictures, etc.)

reg. the deco and because of wayland: i think we'll need a much more abstracted API anyway, because we're unlikley gonna "reparent" into some QWidget on wayland and emulating this (for input and as graphics carrier) would just be restricting.
Ideally i'd say we obtain some images from the deco, convert them to either texture or Picture and let the deco "paint" the result (DecoPainter::drawTile(sx,sy,...) but for eg. oxygen on xrender we either keep those dead slow "create a huge gradient image, upload it and paint it" or have DecoPainter::drawGradient() resolving to OpenGL & xrender directly (while i've no idea about fglrx and xrender gradients - used to be instant fail... couple of years ago ;-)

Benefit would be a huuuge performance gain by bypasing all the convert/upload stuff, but i'm not sure how to get that "compatible" with QML...

- Thomas

On December 28th, 2012, 2:19 p.m., Thomas Lübking wrote:

... and i'm betting your ... little finger ... that this is gonna fix it ;-)

nope.
But 1. is there absolutely no guarantee to deconstruct sth. on the stack right when the context ends (thus whenever you want to use sth. just painted, rather ::end() explicitly) and 2. should we ensure that everything is actually done.