We see significant increases in speed using the vertex buffer caching on window, so I am not sure about the claims that it is slower.
I appreciate you guys helping out with this one. I don’t work on Linux, so it is hard for me to tie this down.
Some threads on opengl.org on this issue:
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009156.html
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009521.html
Info on VBO from NVidia. I didn’t know about this paper when I wrote the VBO support for Xith3d, so there is always a possibility that I made a mistake that is causing it to crash on Linux.
It was slower for me in jogl test programs.
Some extra info
http://groups.yahoo.com/group/opengl-gamedev-l/message/23108
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010483.html
http://www.delphi3d.net/forums/viewtopic.php?t=154
Generally - 4x nvidia drivers have problems with VBO, which are fixed in 5x version.
As far as VBO is concerned, I wonder how many people were able to discover difference between STREAMING and DYNAMIC modes for VBO reading only ARB spec… Week or two ago nvidia has created a document which explains it in more detail (http://developer.nvidia.com/object/using_VBOs.html)
Due to the fact that there are some bugs in the linux implementation, I still think having it off by default would be best. Now that there is confusion as to the benifits and possibly bugs in the third-party driver implementations, there’s more reason to turn it off by default until all these issues have been resolved.
Don’t forget that it is only one line of java code to turn it back on for your application:
// cp is your CanvasPeer
cp.getRenderOptions().setOption(Option.USE_VERTEX_BUFFER_CACHING, true);
ref: http://xith.org/tutes/GettingStarted/html/using_renderoptions.html
Will.
All demos work for me now on linux with the new 53.28 nvidia linux drivers and XITH3D_USE_VERTEX_BUFFER_CHACHING enabled.
…unless someone turned vertex buffers off in xith the hard way 
regards
Martin
I too have downloaded the latest drivers and they seem to solve the problem. 
good stuff.
Will.
Yes, I also can confirm that 53.28 drivers fix this issue on Linux.
So, what should be the action on this? Shouls we enable VBOs by default now (I mean in jnlp files) or we will wait a bit while majority will upgrade? Does it make sense to recommend to test driver version before enabling VBOs? Should we add such test (read: NVidia bug workaround) in core Xith3D renderer?
Yuri
+1 for adding such a test to the Xith3D core renderer.
defiantly wait a bit for the JNLP, especially since none of the demo’s really need it turned on.
In a few months we may as well turn it back on however.
When you say a driver check do you mean it would just print out “Warning you are using old, incompatable drivers” or somthing like that?. If so, +1
Will.
[quote]When you say a driver check do you mean it would just print out “Warning you are using old, incompatable drivers” or somthing like that?.
[/quote]
Action above plus disable VBOs if not EXPLICITLY enabled - we know one combination (Linux+NVidia drvs < 53.28) where it does not work. This is to-be-added to CanvasPeerImpl. This is how I see this.
Suggested check implementation: check GL’s class name if it contains substring .x11. - then we are on *nix, then check renderer string for NVIDIA, then extract version, and if < 53.28 - check passes.
Yuri
Ok, just clarifying, what do you mean by “disable VBOs if not EXPLICITLY enabled”?
Are you suggesting turning it off across the board by default, or just for Linux NVIDIA users with the older drivers?
Either way, it all sounds fine to me.
Will.
I meant that if there is no option specified it will be enabled for everybody except ones using Linux+NVidia<53.28, if option specified then it will ignore driver detection and use setting from sys props.
Yuri
That’s exactly how it should work.
excellent.
Will.