[squeak-dev] Re: OpenGL (better drivers) on Win32

Andreas Raab andreas.raab at gmx.de
Sun Feb 8 20:17:44 UTC 2009


Kevin wrote:
> 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.

You should really use the OpenGL driver that is provided by your 
graphics card vendor.

> 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.

First, if you were using Balloon3D then you most likely run the software 
renderer. Second, if you have the drivers from your graphics card vendor 
installed, using "opengl32.dll" is the right name to use - Microsofts 
driver model makes these custom drivers available through opengl32.dll.

> 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?

By a process that I ran in 2002 or so. The code which generated this is 
now lost.

> 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.

Then check out OpenGL>>privateInstallLibrary: and 
OpenGL>>openGLLibraryName. Both do exactly what you describe except that 
their purpose is to deal with cross-platform situations.

> 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.

You don't have to recreate it. This is done dynamically when you create 
an OpenGL instance.

> 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.

It does straight to OpenGL. I think you are confused by the Balloon3D 
software renderer.

> 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.

Croquet does. Balloon3D does not (by default).

> 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!

Again, I think you're just confused by the Balloon3D software renderer.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list