FontSmoother 2 & Overclock

[lhandra]

Well, i dont know if this issue ever mention before on the FontSmoother thread or not.

I use Treo 650.
Before i active FonthSmoother i check my CPU benchmarking using Speedy 6.3 and get the result 273 Mhz (276 Mhz standard).
But when i active FontSmoother 2.0 and check again with Speedy 6.3 i got the new result about 313 - 316 Mhz.

Do fontsmoother do a little bit overclocking on CPU speed. Or just speedy use method that can affect on benchmarking result when FontSmoother On ?

The strange is if you use the antialias font like "utopia" the CPU speed will be overclock but when u use standard font from Font4OS (like handera) the CPU speed is normal (on SPeedy 6.3).

[pruss]

I expect it's a problem with Speedy. I've seen a report of this before.

Alex

[lhandra]

I expect it's a problem with Speedy. I've seen a report of this before.

Alex
Thanks Alex :)

[_Em]

The issue is probably that Alex bypasses some of the font layout routines that speedy uses in its tests. The upside of this is that if Alex can make his routines blit faster than the original font handling code, you could actually see a real performance increase :) Does that sound possible Alex? --I know the PalmOS 4.x font code was slow and bloated, but I haven't really looked at the POS5 stuff.

[pruss]

My routines blit much slower than the original font handling code. Especially in alpha-blending mode. But my character width and related routines might be faster than the ROM ones, I don't know.

[_Em]

Hmm... I wonder if making alpha blending an option instead of a given could cause a speed increase in apps where it is disabled?

[pruss]

Hmm... I wonder if making alpha blending an option instead of a given could cause a speed increase in apps where it is disabled?

Alpha blending is automatically used if the app uses overlay paint mode in WinPaintChars() or if the app uses WinEraseChars(). It would look bad without it. However, alpha blending is disabled in Blazer, because of the way Blazer draws text (it draws it several times, which would destroy the antialiasing if I used alpha blending).

Normally, apps draw text with WinDrawChars() and then there is no alpha blending.

Another slowdown is that I don't want to fool around with drawing text directly to the screen buffer (problems with rotation, etc.), and so I draw text to an off-screen buffer and copy. This could be fixed, but users aren't complaining about refresh speed, and I don't want to change core code lest I introduce instabilities.