Ian Romanick wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam Jackson wrote:
My concern with backing this out is how it affects the indirect rendering
case, if at all. I would prefer that clients not be able to crash the server
by enabling client state and then not filling it in; although it appears to
"work" in indirect mode as it is, so maybe I'm misguided.
I don't think this case can occur with indirect rendering. When
indirect rendering is used, the client library packages up all the
enabled arrays and ships all the data to the server. The server then
takes the data that came from the client and enables the array state for
the data that is present.
Huh?
The GLX library should unroll/expand vertex arrays into ordinary
glVertex/Color/Normal/Etc calls which get sent over the wire.
The server doesn't know anything about vertex arrays (VBOs aside).
The calls that the client application makes
to glClientStateEnable never (directly) get to the server.
If the array pointers were NULL, the client would tank before any data
got to the server.
Things (will) work a little differently when server-side VBOs are
implemented. In that case commands will be directly sent to the server
for glClientStateEnable commands, but those enables will only be used
when a VBO is enabled on those arrays.
Also, there's code in Mesa that does bounds checking on references to
VBO data. So it should be impossible to crash the server by trying to
access data beyond the end (or beginning) of a VBO.
My goal is to have the VBO protocol done (it's 95% done now) and voted
on at the March ARB meeting. It's the 3rd or 4th thing in my queue
right now, so that should be a reasonable goal.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
