Login to Account Create an Account
Posted 15 February 2009 - 01:08 AM
Posted 15 February 2009 - 04:27 PM
Other than that, things seem faster... What painting bug was re-introduced in 0.6.2? Didn't notice anything.
EDIT: Some menus are showing up blank until hovered over. Not present in 0.6.2 (last version I kept)
Edited by Colonel O'Neill, 15 February 2009 - 07:23 PM.
Posted 16 February 2009 - 09:29 PM
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.
Edited by WildBill, 16 February 2009 - 09:30 PM.
Posted 17 February 2009 - 06:43 PM
If you move the mouse really quickly across the menu, you'll see that the text will "jump out at you". Granted this is the same behavior as before, although in 0.6.6 it left the reminants of the text. Now, it doesn't.
Given it's kind of hard to screenshot something that only appears while in motion... I hope I've explained it well enough...
It's not interfering with anything, just kind of an eyesore.
Posted 18 February 2009 - 05:18 PM
It's configured to start upon login, and I never get any problems.
Posted 18 February 2009 - 09:54 PM
Now it's just always there.
Posted 18 February 2009 - 11:23 PM
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.
Posted 20 February 2009 - 08:50 PM
Oo I never noticed that until now... Don't know how far back this bug goes.
Also a bug with WinRAR is fixed now: The addition/extraction process won't budge unless I rapidly move my cursor over the window. Now it just works.
FF3.0.6 setup freezes at Choose what type of install dialog as well...
Posted 20 February 2009 - 11:09 PM
I'm working on version 0.6.9 but I haven't nailed down the Firefox bug yet.
Posted 21 February 2009 - 02:27 AM
Edited by WildBill, 21 February 2009 - 02:27 AM.
Posted 21 February 2009 - 08:15 PM
Posted 21 February 2009 - 09:08 PM
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.
Posted 21 February 2009 - 11:41 PM
Posted 22 February 2009 - 12:26 AM
Posted 22 February 2009 - 12:33 AM
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.
Posted 22 February 2009 - 01:42 PM
First things first, I have only been using SmoothText for a few weeks, but I find it really great.
I would like to suggest a new feature, for your consideration.
Would it be possible to add a slider, to customise the "level" of anti-aliasing rendered by SmoothText?
The slider would have 0 on one end (no anti-aliasing at all) and 100% at the other end, corresponding to a really "thick" and/or smoothed font rendering. 50% could be the current behaviour.
Not knowing the details of the present rendering algorithm, I would imagine that the slider could tune the width of the energy distribution curve around the central (sub-)pixel.
In practice, this would work in a way somewhat similar to the Advanced tab in Microsoft's ClearType Tuner PowerToy (Windows XP only):
Or, to give an example which runs on most OSs, this would work a bit like the Tune function in this freeware little demo:
FYI - I'm suggesting this new feature as your very first post got me thinking: "It's not quite ClearType™, but...". Assuming it's feasible, this could virtually close the gap.
Posted 22 February 2009 - 06:38 PM
An uhoh on the explorer menu bars. They are thinner than the others. (The menus themselves have thinner text as well.) The thin text is not unlike the IE bug posted above.
Any pop-up menu from explorer has the same expanding then shrinking text on hover as before. AND all explorer menu's have thinner text. Oo
And as for the adjustable thickness of the text: I do believe I came up with a solution (speed not guaranteed):
Whenever the weighting is changed, SmoothText would then calculate a lookup table between 0 and 255 of integers. Each R, G, B value would be then weighted accordingly. The lookup table is to make it more efficient by avoiding calculating each pixel on the fly.
The lookup table is calculated with the formula:
y = x(1-((c(m-x))/m))
Where x is the input value, c is the scale factor and m is the maximum (255).
infinity < C < infinity,
When C = 0, the function above becomes linear, and the input value = output value. This is the standard as it appears now. When C < 0, the text is bolder, when C > 0, text is thinner. If C > 1, then the low end is cut off.
Edited by Colonel O'Neill, 22 February 2009 - 06:42 PM.
Posted 22 February 2009 - 09:17 PM
Posted 22 February 2009 - 09:26 PM
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.
Posted 22 February 2009 - 09:44 PM
I'm assuming SmoothText has to process each pixel individually after it stretches the font 3x horizontally. As SmoothText processes each pixel from the stretched font, it would have to condense it into either an R, G or B value in one of the destination pixels. As it does this, it looks up a weighted value to use in place of the original. For example:
Original R,G,B values: 0 63 127
Look up each of the R, G, B in the table.
0 ==> 0
63 ==> 95
127 ==> 191
Resulting R,G,B valuse: 0 95 191 - (Note made up numbers)
This means the resulting pixel would be lighter.
Hope that made some sense.
EDIT: Oops didn't notice you introduced that feature in 0.7.1.
It does work, except at the left side it adds a lot of colours (trippy). At the right it's blurry.
My method doesn't pick processors, except it's probably not as fast as any MMX implementation.
Edited by Colonel O'Neill, 22 February 2009 - 09:55 PM.
Posted 22 February 2009 - 10:22 PM
(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).
Posted 23 February 2009 - 12:02 PM
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.
Posted 23 February 2009 - 06:10 PM
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, 23 February 2009 - 08:19 PM.
Posted 23 February 2009 - 08:52 PM
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.
Posted 23 February 2009 - 10:41 PM
I 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...
3 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users