Logged in as Guest Sun, Oct. 21st, 3:07 AM.
|
|
|
|
|
So, I have been doing a little bit of research into direct screen access on the Palm. From everything that I've seen, it appears that there are three ways that direct screen access can be accomplished: 1. WinGetDisplayWindow()->displayAddrV20; 2. WinScreenLock(...); 3. BmpGetBits(WinGetBitmap(WinGetDisplayWindow())); The first method is obsoleted, and even though you can get around it by turning off some of the compiler directives, it fails on most OS 5 devices. Because of that, I won't talk too much more about it here. The second method is basically a double-buffering method. When you call WinScreenLock(), you get a pointer to the offscreen buffer, and all system drawing is performed on the offscreen until you call WinScreenUnlock(). Unfortunately, this method isn't supported on all devices. Strangely enough, it isn't even supported on some newer devices like the original Tungsten T. The third method is the 'safest' method and should work on all devices. However, there has been some discussion about whether or not this actually returns a pointer to VRAM on all devices or if it is 'emulated' on some devices. I can't comment on that since I don't have the source for any vendor implementations, however. The other downside to this is that if you don't perform your screen refresh quickly enough, the user will see flicker, whereas with WinScreenLock, it is guaranteed against flicker. However, if device independance is your goal, then you will definitely want to use the third method. |
|
| Submitted by bosshogg on Wednesday the 31st 1970f December 1969, at 04:00 | |
