Fuzziness in lower resolutions when using absolute metrics

[Sinbad]

I'm using absolute metrics in a window of mine, but the controls (especially fonts) are noticeably 'fuzzier' at lower resolutions, even though the controls are supposedly the exact same pixel size.

Simple example:

Code: Select all

<Window Type="DefaultGUISheet" Name="root">

   <Window Type="DefaultGUISheet" Name="Terrain">

      <Property Name="RelativeMaxSize" Value="w:1 h:1" />
      <Property Name="Size" Value="w:1 h:1" />

      <Window Type="Taharez Frame Window" Name="Terrain/Window">
         <Property Name="MetricsMode" Value="Absolute"/>
         <Property Name="SizingEnabled" Value="False"/>
         <Property Name="Position" Value="x:0 y:0" />
         <Property Name="Size" Value="w:250 h:550" />
         <Property Name="Text" Value="Settings" />
      </Window>
   </Window>

</Window>

</GUILayout>


If you run that layout at 1152x864, it looks nice and crisp, but at 1024x768 and 800x600 it gets noticeably fuzzier. Any idea why?

[jwace81]

I'm not sure that I see the 'fuzziness' that you are referring to, however, it may have something to do with the native resolution of the imageset, and how the scaling is done. When using absolute metrics, a window will not appear the same in all resolutions. This is most obvious by looking at the tiling of the background texture on the window.

J.W.

[CrazyEddie]

The obvious answer is that at lower resolutions things always get a little less crisp just because it is at a lwer resolution.

One phenomenon I noticed was that at various times when writing the system I was testing at very high resolutions (1600x1024 and above) and things look extremely crisp (especially fonts, more on this in a mo), then when switching back to lower resolutions things look much less crisp, I think you notice the effect more when you've been used to seeing it at high res. I don't think it's anything that I've done, though I wouldn't rule it out completely

The auto-scaling that jwace81 mentioned is probably the reason that fonts look so much better at high resolutions. Due to the way that whole system works, at higher resolutions you have more DPI to play with, so I take advantage of this and generate higher quality glyphs - obviously this can't be done at lower resolutions as you just don't have the pixels to play with.

CE.

[Sinbad]

Hmm, I expected that if you used absolute sizing, then the physical pixels written by the gui should be identical no matter what the resolution. I understand that at different resolutions the pixels will be different sizes, so perhaps if I have bad eyesight they might look more blurred, but what I think I'm seeing is that at different resolutions the colour (and maybe the set) of the pixels being written is different.

It's more than just fonts too; I have some sliders which are quite narrow (vertically) such that the edge borders are about a single pixel high - they look fine in 1152x864, but at 800x600 the lines are less distinct, and when you move the window about you can see more 'twinkling' on these vertical lines as (it seems) the filtering blurs different scan lines, which makes it look like there's some relativity involved.

I'll have to do some more tests and post some shots.

[CrazyEddie]

Hmm, I expected that if you used absolute sizing, then the physical pixels written by the gui should be identical no matter what the resolution. I understand that at different resolutions the pixels will be different sizes, so perhaps if I have bad eyesight they might look more blurred, but what I think I'm seeing is that at different resolutions the colour (and maybe the set) of the pixels being written is different.

The scaling system is optional, you can enable or disable it on a per Imageset and/or per Font basis. Currently it's not possible to apply the setting on a per window basis, I guess you could flip the settings appropriately for each window but I have not actually tried this.

The reason this is not synched to the metrics mode setting is because I consider the two systems, and thefore the two sets of options, independant. Though I do see your side of things.

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.

It's more than just fonts too; I have some sliders which are quite narrow (vertically) such that the edge borders are about a single pixel high - they look fine in 1152x864, but at 800x600 the lines are less distinct, and when you move the window about you can see more 'twinkling' on these vertical lines as (it seems) the filtering blurs different scan lines, which makes it look like there's some relativity involved.

Now this 'twinkling' effect I definately know about; there is definately an issue to be resolved here. This is probably about the only part of the system that I'm not really happy with (the same effect sometimes causes gaps to appear between images).

[Sinbad]

The scaling system is optional, you can enable or disable it on a per Imageset and/or per Font basis. Currently it's not possible to apply the setting on a per window basis, I guess you could flip the settings appropriately for each window but I have not actually tried this.

The reason this is not synched to the metrics mode setting is because I consider the two systems, and thefore the two sets of options, independant. Though I do see your side of things.

I'm definitely missing a point here, so apologies in advance.

What confuses me is why any sort of scaling system should affect the final result when you're using absolute metrics. 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?

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.

[CrazyEddie]

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.

[Sinbad]

Ahhh, now I sort of understand what I was seeing when I played with the NativeHorzRes and NativeVertRes on the font definitions (I didn't realise these existed on the imageset definition too). I didn't really understand what they were for, I just noticed that my fonts looked better in 1152x768 if I increased the values in them. That could do with a manual entry That explains why my fonts look fuzzy at 800x600 then.

As for the imagery, since the native size of the taharez imageset is 800x600 I would have thought it would look it's best at that screen resolution, since the autoscaler should conclude that it's 1:1, provided you used the same pixel sizes as your absolute dimensions. In my specific case I have a Taharez MiniHorzScrollbar which is defined to be 10 pixels high in abolute mode. In the taharez configuration file, I see that the mini scrollbar is indeed 10 pixels high (well, the components are between 7 and 10 but I assume the overall natural height is 10). However at 800x600 I get the filtering artefacts.

[Edit]A sudden thought - I've been testing this in windowed mode, and I think the canvas is actually not a full 800x600 in this case because the client area is a subset of the whole window size. This could be the problem, since then the autoscaler won't come out with 1:1. I'll check later...[/Edit]

[CrazyEddie]

Ahhh, now I sort of understand what I was seeing when I played with the NativeHorzRes and NativeVertRes on the font definitions (I didn't realise these existed on the imageset definition too).

Yeah, technically it is an Imageset feature. Fonts are basically a dynamically created Imageset, so they get to use the auto-scaling system too

I didn't really understand what they were for... ...That could do with a manual entry

I think this definately needs a manual entry I should imagine there will be a lot of people who need this explained properly, as there's not much mention of it in the API docs.

[Edit]A sudden thought - I've been testing this in windowed mode, and I think the canvas is actually not a full 800x600 in this case because the client area is a subset of the whole window size. This could be the problem, since then the autoscaler won't come out with 1:1. I'll check later...[/Edit]

You are correct about the windowed mode not giving the full 800x600, and I'll be interested in any results you get. Though when I did some very brief tests a long while back now, I didn't exactly get the results I was looking for . As I said earlier, IMO it's currently the one thing that is spoiling the look of the whole system So I'm definately going to have to get my hands dirty and sort this out. I have a four day weekend, so I may be able to deal with this, though I also want to finish the WindowsLook and play some Doom 3

[Sinbad]

Bingo. The non-800x600-ness of windowed mode was causing the extra filtering because of the imageset autoscaling. If I run it fullscreen at 800x600 the slider borders are all perfectly 1 pixel high, as I would have expected.

There's still a little twinkling on drag, but it's less noticeable now.

Thanks for the help, and good luck for the weekend