WildBill Posted February 23, 2009 Author Share Posted February 23, 2009 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 bufferRABGRABGRABGRABGRABGRABGRA1 2 3 2 1 1 2 3 2 1 1 2 3 2 1resulting multiplier (blanks are zero):1 12 123 232 321 21 1This 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 More sharing options...
bob2000 Posted February 23, 2009 Share Posted February 23, 2009 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 More sharing options...
Colonel O'Neill Posted February 24, 2009 Share Posted February 24, 2009 (edited) Agreed. The fourth position seems to provide the crispest results without introducing too much colour distortion.EDITAddition: It seems the Word 2003 bug was attributed to SmoothText.The fonts that I told to exclude did not exhibit the same behavior. Edited February 24, 2009 by Colonel O'Neill Link to comment Share on other sites More sharing options...
WildBill Posted February 24, 2009 Author Share Posted February 24, 2009 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.3It will depend on your monitor, of course. Link to comment Share on other sites More sharing options...
Colonel O'Neill Posted February 24, 2009 Share Posted February 24, 2009 Word Selection MenuI have MingLiu in the exclusion list (among other Asian fonts).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 More sharing options...
WildBill Posted February 24, 2009 Author Share Posted February 24, 2009 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_correctionThat 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 More sharing options...
bob2000 Posted February 24, 2009 Share Posted February 24, 2009 (edited) 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 February 24, 2009 by bob2000 Link to comment Share on other sites More sharing options...
Colonel O'Neill Posted February 25, 2009 Share Posted February 25, 2009 (edited) Progress has been great. There's still the odd place where SmoothText can't seem to hook itself into... And some things that will oscillate between smoothed and non-smoothed based on mouse hover... Edited February 25, 2009 by Colonel O'Neill Link to comment Share on other sites More sharing options...
WildBill Posted February 25, 2009 Author Share Posted February 25, 2009 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 More sharing options...
hpj2 Posted February 25, 2009 Share Posted February 25, 2009 Hello WildBill,there is still a problem with menu painting. See screenshot from FreeCommander (Windows 2000 Prof. SP4).Some menu entries are painted several times! Link to comment Share on other sites More sharing options...
Colonel O'Neill Posted February 26, 2009 Share Posted February 26, 2009 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 More sharing options...
bob2000 Posted February 26, 2009 Share Posted February 26, 2009 (edited) 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).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 February 26, 2009 by bob2000 Link to comment Share on other sites More sharing options...
WildBill Posted February 27, 2009 Author Share Posted February 27, 2009 (edited) 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:)TextOutExtTextOutDrawStateGrayStringMy 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 February 27, 2009 by WildBill Link to comment Share on other sites More sharing options...
WildBill Posted February 27, 2009 Author Share Posted February 27, 2009 I've posted version 0.7.3, which fixes the FreeCommander menu bug. It also has some other changes (hint: NT4 users out there should try this one).Enjoy... Link to comment Share on other sites More sharing options...
Colonel O'Neill Posted February 27, 2009 Share Posted February 27, 2009 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:(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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now