On Sep 20, 2004, at 9:10 PM, Timothy J.Wood wrote:
From the VBO spec:
UnmapBufferARB returns TRUE unless data values in the buffer's data
store have become corrupted during the period that the buffer was
mapped. Such corruption can be the result of a screen resolution
change or other window-system-dependent event that causes system
heaps such as those for high-performance graphics memory to be
discarded. GL implementations must guarantee that such corruption
can occur only during the periods that a buffer's data store is
mapped. If such corruption has occurred, UnmapBufferARB returns
FALSE, and the contents of the buffer's data store become
undefined.
First off this semantic basically seems to mean "don't use this API
at all" since in order to handle the corruption case, you have to be
maintaining a system-memory copy of the vertex buffer backing store
yourself so you can recover from the corruption (with much the same
inefficiency that APPLE_client_storage helped with). Second, could
the Apple folks expound on this a bit:
- Under what circumstances will Apple's GL *ever* return FALSE for
UnmapBufferARB?
- What synchronization penalty exists for BufferSubDataARB?
Maybe I'm totally off my rocker, but the map/unmap API seems mostly
useless unless all the vendors make some statements about the
robustness on their platform. I suppose I'll never get a response
from all the vendors in the PC world, so the only option would be to
just use it and hope for the best or avoid map/unmap completely.
For full screen apps, this seems like less of a problem (since, of
course, the display will have been captured), but if you have a
windowed GL app running while the user is mucking with their display
settings in System Preferences, horrible, horrible things seem likely
to get drawn :)
This is just verb-age for Windows developers. Lucky them.
UnmapBufferARB will never return FALSE on MacOS X because it corrupted
your data. We don't let your data get corrupted.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
