WildBill

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.

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

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.

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).

Interesting. I don't yet understand it as I've been coding all day, but I'll take a closer look at it. Is it a gamma adjustment? Speed is a real concern, though. I've posted version 0.7.1, which has a bunch of fixes and improvements. I would especially appreciate some feedback on the NT4 feature, as the copy I bought hasn't come in the mail yet and I can't yet test it.

You're welcome. If you ever need associative lists (hashes), you might want to take a look at the STHashes unit in SmoothText's source code. It's in the Win2000 section. Delphi never came with decent hash code and I needed to write it to fill the gap.

Eww. That's ugly -- and weird: I'm not getting that when I run IE. One question: are you running "large fonts" or "small fonts"? I don't think it should make a difference, but it's at least something to potentially rule out.

Someone has asked me to see if I can make SmoothText work on NT4, and it might be possible. Would anyone be able to post or send me a list of all the functions that NT4's GDI32.dll exports? That way I would know which routines to exclude with compiler directives.

Hmm. Word 2003 bug? I was wondering. Anyhow, I've posted 0.7.0 which I'm hoping will fix the tab font bug. Of course, I've been trying to fix it for a while, so you never know.

Version 0.6.9 is posted, and it fixes the Firefox 3 setup problem, as well as has a couple of other improvements.

The Firefox bug is the one I was referring to earlier. Just as a sanity check, what happens in Word 2003 if SmoothText isn't running? I'm working on version 0.6.9 but I haven't nailed down the Firefox bug yet.

Wow, thanks for the votes of confidence. I don't have it run on startup, but that's because I'm constantly working on it and a crash bug in the middle of making a new version would be bad for me (though I could have the previous version run on startup, I suppose). I know about the menu issue, but haven't had time to track it down yet. Menus are definitely tricky. Version 0.6.8 is up, and it fixes some rendering problems as well as runs faster. On my Pentium 4, page-scrolling through a document in Word 2000 is about 25% faster (about 8 seconds as opposed to 10). Your mileage may vary of course, but for me it's lightning fast now. I still need to hunt down that bug that's making Firefox 3 setup hang if standard controls are being overridden. That's the top priority at the moment. It's definitely a problem in rendering buttons, but I don't know why yet.

I've posted version 0.6.7, which should have some really solid menu code. I'm even using double-buffering there, so there should be no glitches. Let me know what you think. Text painting should also be a bit faster overall for everything. The painting bugs were really obscure. If I really beat on Delphi, for instance, it would eventually freeze. I haven't had that happen again, but for instance, the FireFox 3 setup program freezes at a certain point (which I can at least easily reproduce). I've narrowed it down to when I override buttons, but I don't know why yet.

Hmm. There were still bugs to be fixed, so here is version 0.6.6. Hopefully this takes care of them.

Sorry for the rapid update, but I had introduced a bug in 0.6.4 that really needed to be fixed. 0.6.5 should fix the problem...

Here is version 0.6.4, with some small improvements. Enjoy...

Version 0.6.3 is now posted, which can smooth text on pop-up and drop-down menus, but not top-level menu bars. One step at a time...

I haven't seen any shift in Firefox...what browser are you using? You might be right about the cursor. Maybe I need to research it and turn the cursor off before painting and on afterward? I'll have to look into it. On a better note, in my test version I have menu text being smoothed nicely, now, with the exception of top-level menu bars. Tomorrow I'll take a look to see if I can get that smoothing as well.

I'm glad to hear it. I've posted version 0.6.2 tonight, which should fix some painting issues.

I've made some more optimizations, and I think I have the slowdown issues licked. Its hellaciously fast, now. One annoyance is that the taskbar font bug is still occasionally rearing its head, though not nearly as often now. That's something I'll have to tackle going forward. Anyhow, version 0.6.1 is posted, and it downright blazes.

There's definitely still a slowdown bug that I'm working on fixing. I've narrowed it down to my double buffer and I think it's because the buffer grows over time to accommodate text. I'm testing a fix right now, but I won't know if it works for a little while.

Version 0.6.0 is now posted. I've really tried to hyper-optimize the caching to try to maximize speed, and I've made a couple of small improvements. Enjoy...

That's great. I definitely need testers, LOL Please let me know if you run into any issues. I've made some more slight optimizations for 0.6.0 (and simplified some code), but I'd like to sit on it for at least a few days to see if any issues crop up before I release it.

I really, really hate obscure bugs Version 0.5.9 is posted, which fixes a really hard-to-find bug in the caching code that was causing the cache to become corrupted.

All day I had planned to work on TClock3, but it turned out that I had to work on SmoothText first Version 0.5.8 is posted, and in some ways it's a huge improvement. I'm getting blazing speed in Firefox now