CEGUI (Crazy Eddie's GUI) Forums

While experimenting with the GUI (which is great) it came to my mind to use a smaller font. I changed the font size in the xml file but after that it looked kinda blurry. I tried not to autoresize the fonts. I tried other fonts. I tried to turn antialiasing off (*uargs*).

Is there a way to get small readable fonts like the windows default system font that looks good at a font size of 10 or below?

I tried to turn antialiasing off (*uargs*).

Does this mean that you did turn it off, or just that you tried? As my suggestion was going to be (and still is) to turn off antialiasing for the font, lol.

I don't know that any thing else is possible; unless you create a bitmapped font, though I guess you don't want ot go that route...

CE.

I did turn anti aliasing off. Font got sharper but look really awful. You are correct. I don't want to create bitmapped fonts. Thanks anyway.

I experimented a bit. I use Absolute Metrics mode to position and size some buttons. I turned auto font scaling and image scaling off. The text inside some of the buttons looks good. Some other buttons of the same size look unsharp somehow. The reason for this is that the text of the button is centered. When the text size is an odd number the text image is placed "unaligned" to the screen pixels. When not everything is fine.

As a workaround I did this:

All buttons with even text width get even length and buttons with odd width get odd length. The one pixel difference in width is hardly noticable.

Right, I think I know what you're seeing. Sinbad mentioned this a while back; the issue is basically caused by the texture filtering used. It's the same thing that causes 'twinkling' of the imagery as it's moved across the display. I intend, at some stage, to resolve this issue (it's funny, the C#/Axiom version does not seem to have the same problem ).

CE.

May be you could internally align all text, and image positions to integers? This is basically what I'm trying to do do now on the client. May be there is a bug in the C#/Axiom version that does that unintentionally?

I couldn't sit and wait and played a bit with your code.

In Imageset::draw( ) I adjusted the destination rect's position so be integer aligned. While this works good for me it will surely corrupt layout of other programs using CEGUI. There will be seams between controls I think.

Another solution that comes to my mind would be to change a lot of code inside control implementations to make sure no control is placed "unaligned" and that neighboring windows inside controls have no unwanted gaps.

Edit: Just tried to hack the controls I use (Checkbox, PushButton, StaticText, Edit) to place their inner text or child windows integer aligned to the parents position. As long as these controls are moved integer aligned now everything is sharp and not flickering. I also modified the text output in the font class to be align on screen coordinated in case of centered output.

Hi,

I'm glad you managed to get some results you like from your tests

Any final solution also needs to work for relative metrics and for cases where auto-scaling is enabled, I do not know if your tests included these cases or not. I did do some minor tests and hacks of my own relating to this back around May/June time, and, as aready mentioned, will re-visit the problem again. Although at the moment it's not one of the things that I consider a priority.

CE.

In my opinion the relative adressing mode and the autoscaling is the source of flickering and blurryness. If there is an inconsistent mapping between screen pixels and texels it will flicker and get blurry. I don't see how to prevent that. So if the client wants autoscaling and relative adressing it must be aware of that.

If the client doesn't want this there are serveral things to be done one the client side:

1. All window positions should be integer aligned in screen space.
2. Auto resizing should be turned off for images and fonts.

Now there is only one thing left to be done inside the library. The controls should place their client windows integer aligned in screen space too. May be a better solution is to align client windows inside controls on the scaling factors so no "jumping" occurs when autosizing is not turned off. The problem is that it is a lot of work rewriting the controls. The fact that code for placement of child windows in controls is not only in the base library but also in the implementations of specific looks doesn't make it easier.

I understand that you have other priorities but may be you find the time to tell me what you think about that.

While your analysis may (or may not ) be correct, and your solution generally feasable, I think it overcomplicates things to the extreme. There should be no need what so ever to code work-arounds into every single widget that ever gets developed.

If the same issue is indeed present in all five renderers, then a fix should be developed and applied at the Imageset level. If this were to turn out to be problematic, or if only some of the renderers are affected, then the renderers themsleves should be changed to fix the issue.

CE.

Hello Eddy,

I hope I'm not buggin you too much . I tested the other demos from the download section and the flickering is present with ogre and OpenGL renderes as well.

I tried to find a more general solution and I think the results are quite good.

1. I removed the fractional parts of all absolute coordinates in Window::relativeToAbsolute, Window::windowToScreen, Window::setPosition and Window::setSize functions. This resolves most of the flickering and unsharpness.

2. I changed Font::drawWrappedText so that the text position is integer aligned too.

3. I slightly tweaked some controls that rely on child windows positioned directly neighbouring each other like the MultiColumnList so no seams show up between columns. The fractional parts of the scrollbar positions were removed too.

In my opinion the output is just stunning. I tested it with the d3d9 gui demo and it worked flawlessly at first glance. No flickering when a window is resized and everything is sharp. May be this helps you a bit when you address this issue in the future.

Markus

You're not bugging me particularly It is to be expected that users priorities will not always be the same as what mine are; so these kinds of discussions are inevitable

Thanks for posting what you have done to achieve your results, I'll certainly keep your points in mind.

To go off slightly on a tangent; did you by any chance do any before and after profiling? I'd be interested in how the float to int conversions and other adjustments affected things on the performance side. I'm sure the FPS are around the same; I'm mainly interesed if there is any change in which methods are most expensive

CE.

Sorry for answering so late. I have been busy with work. I used floor() to cut off the fractional part so I think compiler intrinsics will kick in. I didn't do any profiling but as you already expected the framerate of the sample app didn't change at all. Sp I made some screenshot at least, Please note that I changed the font size to 8 as this was my original intention




Regards,

Markus

This looks very good. I wonder if this is a similar approach that CE did recently on the redone demo 7 I think it was.

Hi,

Nice screenshot

After this thread went quiet, mention of the problem was made over on the Ogre forums and I decided I'd do a small test. The results of that test made me realise that the issue was much bigger than I had originally thought; so in this respect I apologise for my earlier reluctance to fix the problem

However, having acknowledged the issue was more serious, I gave it top priority and it is now fixed in CVS-HEAD.

Btw, I profiled std::floorf versus an approach that used casting; the casting version out performed the std::floorf version by quite a bit, so this is what's used in the code. Having said this, I have implemented the fixes via a preprocessor macro, which enables the fix to be changed to use other techniques should the need arise, and also to turn it off entirely (there's an option in CEGUIConfig.h for this).

CE.