I'm definitely missing a point here, so apologies in advance.
I think we've each just got a couple of wires crossed
What confuses me is why any sort of scaling system should affect the final result when you're using absolute metrics.
It probably shouldn't. I'll try to elaborate on a couple of bits about the way things are structured...
The (optional) "scaling-system" I'm talking about is built into the Image/Imageset classes, and is implemented in such a way that when a widget gets the size of an Image it uses for rendering, the returned results are pre-scaled by (displaySize / nativeSize). The windowing system that is built on top of the Image/Imageset system has no knowledge that anything like this is going on, it's totally transparent.
The windowing system has the notion of absolute and relative metrics, as you know. Regardless of what this metrics mode is set to, the render methods will query an Imageset for the sizes of the various images it uses so that it can properly arrange the imagery and render itself. The key point here is that the sizes it gets back from the Image/Imageset will have been modified to remain resolution independant (which is probably undesirable when the window is using absolute metrics).
The solution I see at present is for the each window/widget to enable/disable this scaling on each Font/Imageset used according to it's (that is the Windows) metrics mode setting. We can't just set this setting and be done with it, because the windows can use differing metrics mode settings. This then leads us to another issue; a window in absolute mode (and using non-scaled images) will look totally different to a window of exactly the same size in relative metrics mode (using scaled images). One of the demos had an option to allow you to flip the auto-scaling system off and on, this demonstrated what the system does.
I do understand your point about not wanting the scaling in absolute mode, one example would be that a buttons label text would not fit within an absolute mode button when drawn at higher resolutions; so there's definately an issue here that needs to be addressed. Though it would have been nice if somebody had mentioned it before now
If by scaling system you mean the process of mapping texels to pixels, I don't see why there should be a variation when running in different resolutions. Surely if you have a 50x50 area in the texture which is scaled to (say) 40x40 in the final screen image, whether that 40x40 area is in a 1152x864 screen resolution or a 800x600 resolution should be irrelevant, shouldn't it?
I wasn't actually talking about texel mappings, beyond the Renderer class, the entire system basically a 2D 'sprite' based system.
The actual colours written should always remain the same, all the scaling system does is change the size of the quad geometry used for the images, nothing more.
What I meant was that because the filtering is not consistent, the final pixel colour ends up being different, even though it's being rendered in the same original colour. This is most noticeable when you have thin lines, since filtering can make them darker (in the taharez look since it has a black background). In my case the sliders are darker at 800x600 than 1152x864. This is what makes me think the final pixel size of the control is not constant between resolutions when in absolute metrics mode.
I definitely need to post some shots, I'll do that tonight.
Yes, I understand this fully, since I also see the effect you're referring to, and want to get it fixed also.