--===============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
Testing <= /h1>
Bugs:
312209
Diffs=
|