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

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

2009/2/8 Kevin <[hidden email]>: it was generated a while ago by someone (don't remember who). About 2
years ago i tried to find these sources as well, withotut much success
:)
you could replace a .dll name using single swift blow:

ExternalLibraryFunction allInstancesDo: [:fn |
  (fn module = 'opengl32.dll') ifTrue: [ fn setModule: 'yourdll.dll' ] ].
this is a little dangerous, because VM is caching these pointers.
Save before doing it, and expect that your update may not work unless
you restart the VM.

Concerning the speed.. i don't think that you will gain much from
replacing a library. :)
I suspect you got slooow numbers because you rendering in software
mode, without hardware acceleration.


> --kevin
>

--
Best regards,
Igor Stasenko AKA sig.

> From: Igor Stasenko
>
> you could replace a .dll name using single swift blow:
>
> ExternalLibraryFunction allInstancesDo: [:fn |
>   (fn module = 'opengl32.dll') ifTrue: [ fn setModule:
> 'yourdll.dll' ] ]. this is a little dangerous, because VM is
> caching these pointers. Save before doing it, and expect that
> your update may not work unless you restart the VM.

Thanks for the suggestion! ...using that allInstancesDo: with
a Transcript show: fn module. shows that my change to 'opengl.dll'
is incorporated into the methods' bytecodes; browsing the methods
and looking at bytecode view confirms it.  So, okay; now to find
out if I'm actually getting the new dll.

...Okay, weird; I'm seeing 'opengl.dll' as the module name in the
OpenGL methods; I've renamed my opengl.dll to hide it; and restarted
Squeak.  And the OpenGL calls are still working!  (slowly, and
hardware accelation still fails; see below).  Now to figure out about
this cache of which you speak.  :-)


> Concerning the speed.. i don't think that you will gain much
> from replacing a library. :) I suspect you got slooow numbers
> because you rendering in software mode, without hardware acceleration.

Yes... in fact what started me down this path was that when trying out
the B3DSceneExplorerMorph (rotating cube) there's an 'Enable hardware
acceration' checkbox; selecting it gives a walkback:  'Error: a primitive
has failed'.  Looking at it closer now, the primitive failing is
b3dInitializeRasterizerState in module Squeak3D; and since I'm doing
this in a Croquet(cobalt) VM that I loaded Balloon3D back into, I'm
guessing that Croquet breaks Balloon3D and that's why it was unloaded
in the first place.


So anyway... I've got some experimentin' to do.  A thing I really like
about Squeak and smalltalk in general is the possibility of having all
the code I've got always available, live, in the development environment.
And there is a lotta, lotta code in all the various squeak packages.  The
only trouble sometimes is figuring out how to get all the pieces to play
well together.  


Thanks,

--kevin

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

My issues with getting (non-squeak) OpenGL demos to work with
default driver setup (freshly updated Nvidia driver) had me
doubting everything.


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

'Confused' is certainly the right word. :-)  

Thanks for the comments --from someone whose name shows up all
thru the source.  It's a big system that's been growing for a
long time; a little guidance from people that have been in it,
helps a lot.

Cheers...
--kevin