On Fri, Oct 10, 2003 at 03:16:45PM -0700, Ian Romanick wrote: | | Since I was part of that working group, I'd like to clarify why some of | those decisions were made. ...
Apologies if I sounded too critical -- I agree that compromise was a reasonable thing to do in the VBO case. | ... In that case it wasn't just Windows | "issues." ... Yes, though the Windows design flaws are real, too. They affected a lot of other extension and implementation designs before VBOs came along. | ... The big problem was (and will continue to be) power managment | events. ... The trend is clearly toward making these sorts of things invisible to apps that don't explicitly ask for notification about them. For that matter, the trend is to make even less-dramatic events (like window exposures) invisible to most apps. VBOs are something of a special case -- a very low-level interface intended for use by experts who understand the risks. If it had been practical to make mapped buffer objects non-volatile, though, it still would have been worthwhile. It would have eliminated some awkward error conditions that the spec takes pains to handle, and that some developers will undoubtedly trip over. Allen ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
