DLSauers posted on Sun, 24 Jun 2012 22:25:38 +0000 as excerpted: > On Sun, 24 Jun 2012 11:04:27 +0000, Duncan wrote: > >> But you're /still/ not getting it. "Think outside the screen!" =:^) >> >> The resolution of the pan-window image in that link is only 1600x865, >> presumably maximized to your screen size, but that's *NOT* the limit on >> the size of the window and NOT what I'm talking about. > > Thank you, now that I understand what your saying, KSnapshot and xwd > still just will not co-operate.
=:^( But at least you understand the concept, now. I was hoping... (As I said I had used the technique for big windows before, but for other purposes (movie zooming, FWIW, was one purpose, I have two monitors stacked and wanted to play it full screen over both, tho obviously only showing the onscreen part... it worked), not snapshots, so I didn't know for sure whether that would work... I guess we know, now.) > KSnapshot comes close, but it creates a mangled image for some reason. > > I even tried this on a rebuilt base distro from 12.04 Precise and Pan > 0.138... image displays fine, won't save via save attachments Yeah, pan hasn't seen any serious changes in that code in some time, IIRC, tho it might have since 0.133. But I think it's pretty much as Charles left it. > 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. If you have the resources, you could try on a machine with different graphics hardware, or with the free vs. proprietary drivers, with KMS vs UMS, or even with different relative versions of driver/mesa/X/kernel (easiest is probably trying various liveCD/DVD/thumbdrive distros with older vs newer graphics stacks) etc. Also, try with tiled vs. untiled layout -- that's actually one of the first things I'd try as if it's tiled and ksnapshot is expecting a standard framebuffer layout, it /would/ appear scrambled. What's apparently happening is that ksnapshot is assuming some sort of backing-store memory formatting for that window, while the hardware/ driver is using something different... like tiled vs. straight framebuffer layout. So the memory is read in the wrong order and the image, while probably the correct size and colors, is scrambled pixels. Thus the idea of trying all those things to see if you can get a matchup. At the desperate end, consider switching to basic, unaccelerated framebuffer drivers, temporarily. The system will likely be dramatically slower, but if it lays out the window image in an order ksnapshot can grab it... > So it will take a change to Pan to have a right click save attachment > that does not re-decode the image via the routines it currently uses. > > Is this bug material? Feature request? I suspect Heinrich is already investigating. As I said, I don't think he's touched that bit of the code much, so he may be having to wrap his mind around what Charles was doing and why Charles chose two different decode implementations for display vs. save. (I believe Charles still hangs around in the pan IRC channel, tho I'm not an IRC guy, and IIRC they have his email if necessary as well, so they could actually ask him if it comes to that. Whether he'd remember... but I think he might, since it was probably due to a bug of some sort. The question is whether that bug still applies to reasonably current libraries, etc, or not.) But Walt knows more about the code than I do. I'm mostly just interpolating between what he has posted and what I've (not) seen show up in the git logs since Heinrich or the changelogs before that, plus my memory of the Charles age and the pan rewrite. I'd consider bugging it, but wait a week or so and see if Heinrich comments first. He may well be looking at it already, and he tends to code rather than post, which isn't a bad thing for those that /can/ code. (That's actually one of the reasons I originally became a list regular a decade or so ago, with the idea that if I could answer some of the questions, that would allow the people that could code, to spend more time doing so instead of answering questions themselves.) -- 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
