[squeak-dev] OpenGL (better drivers) on Win32
Kevin
kevin at kelleysoft.com
Sun Feb 8 15:34:02 UTC 2009
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
More information about the Squeak-dev
mailing list
|