It has been my experience that the single greatest cause of slow speed
in a function is GENERALITY. Many OSes, for example, Windows and BeOS,
have seen fit to give developers a set of non-general performance
operations for graphics, because even a one gigahertz desktop can't
compensate for the generality required of formal OS calls.
For example, Palm could offer a performance "copy buffer to screen
function" that ASSUMES:
-> An entire screen copy (or at least a screen-WIDE rect copy)
-> suitable memory alignment for maximum transfer speed
-> * Buffer is in EXACTLY the same format as the screen, including pitch
(rowbytes)
I see no reason why such a function should be any slower than my illegal
code.
Then, if Palm is further worried about potential errors if the user's
buffer really doesn't match, Palm could add robyustness and control with
a function like CreateScreenBufferBitmap, which would ensure that the
screen matches. If the screen changes, a single compare would then
suffice to head off the BLiT.
It wouldn't take very many non-general, performance functions to give a
lot of legal power to game developers. Currently, I've found that my
unoptimized C code is eight times faster than WinCopyRectangle, and I
can only assume that's because my function is not general, but designed
with the above assumptions.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
