Hi ! I noticed that the Palm Simulator does not complain when you directly access video RAM, unlike POSE : does it mean it will now be "tolerated" and that we can "officially" do it in the future ?
Yes, I know : directly accessing the video RAM is "bad", but it's sometimes the only way to have good enough performances. As all of the necessary information ( width and height in pixels, depth, location of the screen in memory, number of bytes per line ) are available via API calls ( not structures... ), I'm wondering if it is not possible to "legalize" it ? Of course, POSE can always check that we don't read/write outside of the screen, by comparing the memory location which should be >= ptr and < ptr+(height*rowbytes). If there is some really good reasons to not allow that, we should at least be able to use the pointer returned by WinScreenLock ! Currently, if you use something else than MemMove to access the memory location returned by WinScreenLock, POSE complain... As there is no simple way ( to my knowledge ) allowing to create a WinHandle from the value returned by WinScreenLock, and if we really don't have the "right" to use this pointer I'm wondering if this function is really usefull ? In fact yes, allowing hardware flipping ( which is the purpose of WinScreenLock ) is really cool if you want to have fast and nice animations, because it's the best way to update an offscreen window and to "blitt" it instantaneaously into the visible one without any glitch and without the need of another copy, as the visible screen location just need to be updated. WinScreenLock/WinScreenUnlock is a very nice feature, but for the moment it is almost useless : if you want to use it, you must do all your graphic work in a other offscreen window ( having a correct WinHandle ), then copy it's content into the memory location returned by WinScreenLock using MemMove ( which is not the fastest way, but any other produce a complaint from POSE ) and then do the flipping by calling WinScreenUnlock... This is not efficient at all ! The best way would be to be able to draw directly into the memory location returned by WinScreenLock and then flip the windows by calling WinScreenUnlock : a lot faster and visually nice. To do this, you just need to : - "allow" us to use the memory location returned by WinScreenLock - give us a way to create a WinHandle from the value given by WinScreenLock, to be able to use the graphic functions of the API. - make any licensee implement this function, for all devices that have at least Palm OS 3.5 ( the Prism does not support WinScreenLock, which is a shame as it have the same video controller than the m505 which handle it ) What does other developpers think about that, wouldn't it be great ? -- Daniel Morais -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
