Background:  I'm playing around with all the 3D code/examples I can find,
between Croquet/Cobalt, Balloon3D, a bunch of openGL sample code from books
and the net.  In doing this I have demonstrated that the Windows XP openGL
driver (opengl32.dll, the microsoft impl.) is buggy and slow.  In fact if
fails completely to display a lot of simple sample opengl demo programs.  
There's an SGI implementation of OpenGL, comprising files opengl.dll, 
glu.dll, and glut.dll (latter two provide higher-level and windowing
functions I understand).  Using those drivers my various sample programs
work well, fast and clean.
 
Back into squeak, doing some simple 3D demos using openGL in morphic
windows,
and using Balloon3D as a basis... I'm getting some extremely slooooowwww 
drawing with simple (few primitives) models.  It seems squeak on windows is 
using the default (microsoft) openGL drivers; in fact the OpenGLWin32 class
is answering 'opengl32.dll' as the driver name.
 
Also in OpenGL class, categories Keyword API and OpenGL API, are a bunch of 
methods with primitive calls, all of which are calling out the
'opengl32.dll'
library and therefore are using the buggy and slow MS driver.  These methods

all say "This method was automatically generated", so my question is By who?
or what?
 
I could manually edit all those calls to use 'opengl.dll' instead, and thus 
presumably get the better driver, but that's kind of a pain and would have
to 
be done every time I switched to a different image.  I'd rather fix it once 
and be done.
 
Is that auto-generation of primitive calls in OpenGL class being done at the

VM build stage, maybe by VMMaker or something?  Is there a simple re-
initialization I could do, maybe change the OGLWin32>>openGLLibraryName 
method to answer 'opengl.dll' and re-initialize to regenerate those OpenGL 
methods?  I don't see it.
 
Interestingly, the Croquet worlds seem to work pretty well; I'm guessing
some 
of its 3D stuff is being handled in a croquet plugin instead of going
through 
the OpenGL class.  Not sure about that yet.  I'd assumed that croquet would 
be using the same OpenGL implementation as everything else, and so fixing 
OpenGL to use the better driver would make croquet better as well.
 
Anyway, I'm still digging at this problem, and would appreciate comments or 
pointers from anybody that's got an idea what's going on.  Thanks!
 
 
--kevin