Reduced Image Quality for 32x32 Pixel Units
Eric McDonald
mcdonald@phy.cmich.edu
Sun Dec 12 04:21:00 GMT 2004
mskala@ansuz.sooke.bc.ca wrote:
> I'll try building a best_image_in_range function in the kernel - that
> should be easy - but I'm not sure about the interface side of the
> equation.
Excellent. I'll handle the interface side of things once you have the
revised function ready.
>I think that there's a TCL command implemented for the purpose
> of requesting unit images (possibly even the same one you were looking at
> with those crashing bugs I filed recently)
Well, 'imfsample' might be the Tcl/Tk widget you are referring to. The
function that I recently changed to deal with the crash was 'tk_u_image'
or something like that. It simply looked up an IMF to use based on a
name; it didn't have to do with scaling. Matter of fact, there is an
array of IMF's ('uimages', IIRC) that is precalculated at some point,
and the function returned an IMF out of that array. I need to find where
that array is filled out, and I can probably nip some of the interface
issues there.
Speaking of 'imfsample': I believe it is a Tk widget. Under Windows, it
likely has a device context associated with it. If 'imfapp' initializes
3000 or so of these things, that is probably eating up GDI handles (not
to mention heap) like there is no tomorrow. I wonder if there is a good
alternative way to implement its functionality. It might solve some of
the GDI memory problems Hans used to gripe about.
>and that command will need its
> syntax changed or something to deal with the additional arguments, and
> then the TCL code that actually uses that command will need to be updated
> too.
Sure. Of course.
> Now, if there isn't an image in the range and it has to scale, to what
> size should it scale? I'm thinking maybe it should go to the largest end
> of the range - it's going to look blocky for being scaled anyway, so it
> might as well at least be big - but would it be better to have a third
> width/height pair as well, to be the size to scale to if scaling is
> necessary?
That is a good thought. The third pair would also be handy if an image
existed at both ends of the range; it could help decide which one to
use. Since we are compiling as C++ code now, the third pair can probably
be made optional arguments defaulting to -1, which would mean to pick
the largest end of the range, when images exist at both ends or no image
exists in the range: ", int ws = -1, int hs = -1".
> Low-res pixel color problem = the issue of some terrain types disappearing
> at the lowest magnification, right?
Yes. Sorry if I caused you any alarm about a potential new bug.
Eric
More information about the Xconq7
mailing list