   Clientstate and serverstate what's the big deal?
  Hi!Isn't the distinction between server and client state an implementation detail of the driver (or what ever comes next behind the api)? I noticed that the openGL specification makes this distinction. Why do I, an application developer using the API, need to know where the state is stored?
Quote:Original post by quothHi!Isn't the distinction between server and client state an implementation detail of the driver (or what ever comes next behind the api)? I noticed that the openGL specification makes this distinction. Why do I, an application developer using the API, need to know where the state is stored?Normally you don't, however, since OpenGL can run over a network the server state isn't necessarily stored on the same physical machine as the code runs on. (This has both advantages and disadvantages)   ;  That's true.But this seems to be something the implementation of the API has to care about. Why can't GLX decide by it self which part of the state it stores on the client and which it keeps on the server?I think I miss an important difference.   ;Quote:Original post by quothThat's true.But this seems to be something the implementation of the API has to care about. Why can't GLX decide by it self which part of the state it stores on the client and which it keeps on the server?I think I miss an important difference.The point of the serverstate is to avoid having to transmit some information repeatedly to the Graphicscard or renderserver or whatever, things like VBOs, Displaylists, etc would be pointless if they were stored on the client side.As a programmer you don't really have to care though, if you use modern best practices almost everything will be stored on the server side.   