Duncan posted on Mon, 25 Jun 2012 00:12:56 +0000 as excerpted: >> Oversizing the window off the screen, ksnapshot takes a mangled snap >> for some reason.. I am betting/taking it Ksnapshot does not like the >> size and it extending off the screen? > > The mechanisms there get heavily into compositing, OpenGL accel, etc, > and it's quite possible there's different behavior with some graphics > hardware and drivers vs. others.
FWIW, I spent a decent bit of time testing that today, and yes, I found I was on the right track re OpenGL, compositing, etc. FWIW, I tested various kwin/desktop-effects combos, effects off, or on with either opengl or xrender effects, and (qt setting exposed in kde in the kde-4.9 betas I'm running, tho I don't believe it was exposed in kde-4.8 or earlier) native or raster qt-rendering. (The setting in the 4.9 betas has a tooltip saying native is strongly recommended if you're using xrender effects, but opengl effects tend to work best with raster.) Depending on the settings combinations and whether I was trying to snap a gtk-based or qt-based app, I found at least two and I think three entirely different types of off-screen-window corruption. One was simply blacked or neutral-colored out, only the on-screen bit of the window was colored, everything else was the same off-screen color. A second looked like the result of what I described in the earlier post, pixel/tile scrambling due to incorrect ordering, but it appeared to be all from the correct image, at least. A third was obviously corrupted with bits of (opengl-)texture-memory from previously run apps -- it was obviously grabbing from bits of video-ram that it /thought/ contained the image, but that instead contained un-cleared bits of previous images. (A compositing window-manager like kwin, when using opengl, renders each window as a different texture image, then combines them with transparency and other effects to create the final rendered image. So in this case, the video-memory ksnapshot thought was window image, was instead uncleared video-memory from previous window textures.) I *DID* find ONE combination that produced an uncorrupted snapshot, but it ONLY happened with the kde/qt app I was testing. Pan is obviously gtk, not qt, and when I retested with a gtk app, I couldn't get that same combination of options to give me an uncorrupted gtk-app-window ksnapshot. It's worth noting that I don't have any gtk3 on the system, only gtk2 (with both firefox and pan built against gtk2). Gtk3 uses more modern OpenGL effects, etc, so gtk3 apps (including pan if built against gtk3 may or may not react the same as gtk2 apps, here. FWIW, kernel 3.5-rc3-ish (git kernel, actually, amd64/x86_64), xorg- server-1.12.2, mesa-8.0.3, on a Radeon hd4650 card over (obviously old) AGP (amd 8xxx chipset), with the xf86-video-ati freedomware driver. kde-4.8.90 (aka 4.9-beta2), as I said. KMS (kernel mode switching), not UMS (user mode switching, the legacy way). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
