Re: Reduced Image Quality for 32x32 Pixel Units

[Eric McDonald <mcdonald@phy.cmich.edu>]

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