Jump to content

SmoothText 1.1.8


WildBill

Recommended Posts

I'm not really processing each color individually. The algorithm pre-calculates a multiplier, which is broken up across three MMX/XMM registers:

(for the default setting, the distribution is 12321 for each color component)

0 - current byte position in source buffer
RABGRABGRABGRABGRABGRABGRA
1 2 3 2 1
1 2 3 2 1
1 2 3 2 1

resulting multiplier (blanks are zero):
1 12 123 232 321 21 1

This multiplier is applied to the source buffer, which results in three pairs of R,G,B values (where one of the six is zero). They are added together and divided by the total of the weights (9 in the example above) to get the final R,G,B color values. As an optimization, for the MMX and SSE implementations I perform the division by multiplying by 65536/the divisor (65536/9 in this case) and taking the high word result. 0.7.1 lets you change the weights from the default 1,2,3 values, but it still doesn't do any sort of gamma correction by treating different R,G,B brightness values differently. I could implement that, but it would slow things down since I would then have to hit a lookup table twice -- once before the multiply and once before writing the color to the destination buffer (an inverse gamma transformation and a gamma transformation).

Link to comment
Share on other sites


Thanks a lot for implementing the feature this quickly.

I have downloaded version 0.7.1 and I really like the results.

From a few basic tests I have run, SmoothText with a 30% setting for the energy distribution slider (0% being the leftmost setting) looks virtually identical to ClearType.

Note: I used a PC running Windows XP to get results as accurate as possible, with Firefox 3.0.6, Internet Explorer 6.0, Word 2003, and 10pt Verdana for all the tests.

Please let me know if there are other specific tests worth running and/or if you want screenshots of some sort.

Link to comment
Share on other sites

Agreed. The fourth position seems to provide the crispest results without introducing too much colour distortion.

EDIT

Addition: It seems the Word 2003 bug was attributed to SmoothText.

The fonts that I told to exclude did not exhibit the same behavior.

Edited by Colonel O'Neill
Link to comment
Share on other sites

That Word 2003 bug will have to be chased down at some point, then. Could you show me a screenshot of what it looks like with and without SmoothText, or with some fonts excluded?

I've posted version 0.7.2, which has some goodies. Also, if some kind soul could test to see if it works on NT4, I'd appreciate it.

As far as the new gamma correction, what works best for me is:

- energy slider: in the middle

- gamma: 1.3

It will depend on your monitor, of course.

Link to comment
Share on other sites

Word Selection Menu

I have MingLiu in the exclusion list (among other Asian fonts).

39149659.th.jpg

Unfortunately I don't have any NT4 discs... :(

Best combo for me: Energy 6/Gamma 1.40 --- No perceptible slowdowns.

Are you using the function I posted above?

I notice that the Gamma slider will affect text differently based on background color (since you gave that nifty tri-tone). Unfortunately, it won't make text crisper at all colours...

Link to comment
Share on other sites

Thanks for the screenshot. I'll try to figure it out, but I can't guarantee anything.

I'm using the pure gamma correction algorithm, which is pretty similar. As you increase the gamma, black-on-white text will tend to become fainter and white-on-black text will tend to become bolder. The idea is to choose the point where they seem to have the same weight. On many monitors, a gamma of 1 (pure linear response) tends to have black text too bold and white text too faint. According to what I read, it has to do with how the human eye perceives brightness. I used this as my source material:

http://en.wikipedia.org/wiki/Gamma_correction

That said, I'm doing a really rough gamma correction that isn't all that accurate at low intensities, but it's fast (and for text it probably doesn't matter nearly as much as it would for images). I'm basically doing the "correct from 8 bits" correction in this article's first graph:

http://www.graphics.cornell.edu/~westin/gamma/gamma.html

Link to comment
Share on other sites

Excellent work with the Gamma correction slider. It mimics ClearType Tuner's Contrast setting very closely.

I haven't had much time to choose a proper Energy/Gamma setting yet, but it's amazing how finely SmoothText can be tuned with these two sliders.

By the way, very interesting material on Gamma correction: thanks for sharing.

Edited by bob2000
Link to comment
Share on other sites

Can you give me specifics? I'd definitely like to squash remaining bugs, if I can reproduce them. I'm still noticing slowdowns, but they're taking a LOT longer to take hold. It implies a remaining bug somewhere in the caching, but because it takes so long to take effect reproducing it isn't easy.

One little step at a time I've been refactoring SmoothText so it can do more. I would love for it to eventually handle full skinning via one of its "extras", since internally it's a MUCH better design than TClock3. Tonight I separated out the code that paints the standard controls it overrides into a separate painter class, with the idea that I can subclass it with a more capable skin-painter at some point. In reality, when you check "Override standard controls" SmoothText really is skinning those controls, but it does it in a very different way than TClock3 -- it doesn't subclass anything, rather it intercepts paint messages and detects whether a subclass already painted the component. If none has, then SmoothText performs the painting itself when it intercepts the paint message. This makes it impervious to interference by other skinning apps as well as makes startup and shutdown inherently safer. The bugs you're seeing are a result of other non-paint messages telling Windows to repaint the control. One message at a time, I need to intercept them and prevent the repainting. My TClock3 code should be able to provide the roadmap I'll need to do that.

Link to comment
Share on other sites

Hmm... I don't know if this could be attributed to SmoothText... Had the strangest lock-up ever.

Explorer locked up hard, taskman opened. Was unable to interact with any window, except the Windows Security dialog. From there, I logged off. While logging off, Windows showed the End Task dialog for almost every open window/process. Firefox, CTrayServer, MP_Wnd_Hooker, CiceroUIWndFrame, Word, MSN, explorer, etc.

It's probably not SmoothText, but just a heads-up.

Link to comment
Share on other sites

Hi WildBill,

I have been comparing screenshots, both on a Windows 2000 and on a Windows XP system.

The idea was to try and identify 1) any remaining, visual gap between ClearType and SmoothText, and/or 2) any unexpected difference introduced by SmoothText when compared with standard, no anti-aliased text.

What I found, for both comparisons, is the same result: SmoothText doesn't seem to preserve the overall width of the text.

This problem affects different fonts and different sizes in different ways, but it always manifests itself either as a increased/reduced character spacing or an increased/reduced character width (when compared with the same text, rendered with ClearType or no anti-aliasing at all).

To some extent, this issue seems to depend on the Energy slider setting, but not in an obvious, consistant way:

e.g. on the same page, with SmoothText at Energy 6, some text gets slightly expanded in overall width (as SmoothText is turned on), while some other text gets compressed. The problem occurs for all the settings of the Energy slider.

On the contrary, ClearType doesn't introduce any difference in inter-character spacing or character width.

So, as all we're comparing here is width, the comparison is equally valid on Windows 2000 (SmoothText vs. no anti-aliasing) or Windows XP (SmoothText vs. Cleartype).

I have attached two screenshots, the first with ClearType, the second with SmoothText 0.7.2 at Energy6/Gamma1.40 (both on Windows XP).

post-231738-1235665028_thumb.png

post-231738-1235665046_thumb.png

You can look for yourself at the site I have used as reference, BBC News (tested with Firefox 3.0.6 and Internet Explorer 6.0):

http://news.bbc.co.uk/

(Note: At first I thought that this problem had been introduced with the Energy slider, I as have older screenshots of the same website, captured with SmoothText 0.6.1, which were perfetct, width-wise.

But then I looked at other screenshots, same website and still with 0.6.1, but on a different system, and the problem was already there).

Another good test website is eBay, as it uses a lot of Arial and Times New Roman in different sizes and styles (bold, italic, etc.).

Edited by bob2000
Link to comment
Share on other sites

Thanks a lot for the feedback. At least now I have some things to work on ;)

There's a reason why I don't force character placement to match the original spacing. SmoothText is overriding four API drawing functions (ANSI and Unicode versions of each:)

TextOut

ExtTextOut

DrawState

GrayString

My TextOut implementation simply calls ExtTextOut, since ExtTextOut lets me force character placement. My DrawState and GrayString implementations, on the other hand, call the original API routines but with different parameters.

I could do the same thing with DrawState and GrayString that I do with TextOut, that is, call ExtTextOut, and then change my ExtTextOut code to force character placement to exactly match the character placement of the original font. However, I have a reason not to: I have no control over how the glyphs are drawn. If a glyph for the "wide" font is too wide for the forced cell width you'll see characters running into each other. On the other hand, if it's too narrow, you'll see odd spacing between characters. I can only control the overall width of the font, and there's an algorithm that tries to come close, but ultimately Windows' hinting code has the final say on what a character will look like. There are also kerning issues to consider. I suppose I could make it an option, with no guarantee on visual quality (another possibility is to make it an option and also to create an option that lets people tweak the font-width algorithm).

Edited by WildBill
Link to comment
Share on other sites

Wow! SmoothText 98, there's a thought.

This morning, I started up my XP virtual machine (which has ClearType on), I personally found SmoothText to be MUCH more aesthetically pleasing. Granted, SmoothText needs to be tuned to the right settings, at which point it looks great. But, that's a great feature to have over standard ClearType.

=====================================================

One very minor glitch:

18890259.th.jpg

(Rarely is a serif font used on a computer monitor, as it is often more difficult to read.)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...