> 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.
when at palmsource europe 2001, i discussed briefly these types of
issues with David Fedor. it is something i am sure needs to be looked
into from the operating system level.. however, it could become very
troublesome in the event that a licensee does not implement the API
call correctly..
recent discussions over WinScreenLock() are a classic example.
// az
[EMAIL PROTECTED]
http://www.ardiri.com/ <--- free games!
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
