From kwin Fri Dec 28 15:55:23 2012 From: =?utf-8?q?Thomas_L=C3=BCbking?= Date: Fri, 28 Dec 2012 15:55:23 +0000 To: kwin Subject: Re: Review Request: finish & sync screenshot paint before calling ksnapshot Message-Id: <20121228155523.4845.47870 () vidsolbach ! de> X-MARC-Message: https://marc.info/?l=kwin&m=135671013317221 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============5477377265620230198==" --===============5477377265620230198== Content-Type: multipart/alternative; boundary="===============0145760915904811885==" --===============0145760915904811885== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Dec. 28, 2012, 3:17 p.m., Martin Gr=C3=A4=C3=9Flin 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 fr= om an X11 Pixmap any more. /tmp/hash.png, shm or xputimage. the absence of the native graphicssystem is gonna get us much more fun (cur= rent legacy decos, laptop happily segfaulted the x11 server on the raster e= ngine here; xrender backend and raster decos are unusably slooow - so eithe= r 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 abstra= cted API anyway, because we're unlikley gonna "reparent" into some QWidget = on wayland and emulating this (for input and as graphics carrier) would jus= t 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::drawT= ile(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 y= ears ago ;-) Benefit would be a huuuge performance gain by bypasing all the convert/uplo= ad stuff, but i'm not sure how to get that "compatible" with QML... - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107981/#review24110 ----------------------------------------------------------- On Dec. 28, 2012, 2:19 p.m., Thomas L=C3=BCbking wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107981/ > ----------------------------------------------------------- > = > (Updated Dec. 28, 2012, 2:19 p.m.) > = > = > Review request for kwin and Martin Gr=C3=A4=C3=9Flin. > = > = > Description > ------- > = > ... and i'm betting your ... little finger ... that this is gonna fix it = ;-) > = > = > This addresses bug 312209. > http://bugs.kde.org/show_bug.cgi?id=3D312209 > = > = > Diffs > ----- > = > kwin/effects/screenshot/screenshot.cpp 4254c37 = > = > Diff: http://git.reviewboard.kde.org/r/107981/diff/ > = > = > Testing > ------- > = > 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 painte= d, rather ::end() explicitly) and 2. should we ensure that everything is ac= tually done. > = > = > Thanks, > = > Thomas L=C3=BCbking > = > --===============0145760915904811885== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/107981/

On December 28th, 2012, 3:17 p.m., Martin G= r=C3=A4=C3=9Flin wrote:

completel=
y 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 Pix=
map any more.

/tmp/hash.p=
ng, shm or xputimage.

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

reg. the deco and because of wayland: i think we'll need a much more ab=
stracted 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 ei=
ther texture or Picture and let the deco "paint" the result (Deco=
Painter::drawTile(sx,sy,...) but for eg. oxygen on xrender we either keep t=
hose dead slow "create a huge gradient image, upload it and paint it&q=
uot; or have DecoPainter::drawGradient() resolving to OpenGL & xrender =
directly (while i've no idea about fglrx and xrender gradients - used t=
o be instant fail... couple of years ago ;-)

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

- Thomas

On December 28th, 2012, 2:19 p.m., Thomas L=C3=BCbking wrote:

Review request for kwin and Martin Gr=C3=A4=C3=9Flin.

By Thomas L=C3=BCbking.

Updated Dec. 28, 2012, 2:19 p.m.

Descripti= on

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

Testing <= /h1>

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

Bugs: 312209

Diffs=

kwin/effects/screenshot/screenshot.cpp (42= 54c37)

--===============0145760915904811885==-- --===============5477377265620230198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kwin mailing list kwin@kde.org https://mail.kde.org/mailman/listinfo/kwin --===============5477377265620230198==--