Re: [Pan-users] yenc preview v. saving attachments

[Duncan]

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