[squeak-dev] Re: [ANN] Croquet OpenGL on Squeaksource (Re: Trying to
load ALienOpenGL into 4.1 alpha...)
andreas.raab at gmx.de
Tue Mar 30 00:22:18 UTC 2010
On 3/29/2010 4:47 PM, Ross Boylan wrote:
> I have a couple of questions about this.
> First, I thought a lot of the OGL in squeak code required a special vm
> to understand a C style syntax for function calls.
Both parts are incorrect. First, the OpenGL support doesn't require a
special VM. It requires the Balloon 3D plugin to create a rendering
surface but that's about it.
Second, 'syntax' is something not understood by the VM in general. The
VM executes bytecodes and primitives. Syntax is handled by the Parser in
Squeak. In Croquet, we had indeed special support for non-keyword
method(foo, bar) calls but there is no intrinsic need for that. We're
simply mapping all of these into a consistent set of keyword messages by
prefixing them with the #with: keyword. So the mapping looks like here:
In C In Squeak
glGetError() => glGetError
glBegin(mode) => glBegin: mode
glVertex2f(x, y) => glVertex2f: x with: y
glVertex3f(x, y, z) => glVertex3f: x with: y with: z
up until stuff like
glBitmap(w, h, x, y, xm, ym, bm) =>
glBitmap: w with: h with: x with: y with: xm with: ym with: bm
Croquet always supported the keyword syntax, the non-keyword syntax was
an addition that turned out to be much less useful than we had
originally thought. When I posted the MC package I simply removed all
the non-keyword methods.
> Second, does the later message
>> Yeah, I was wondering why it's so much slower in trunk than in our
>> internal images or Croquet. First I thought it's the JIT but then I
>> looked at a profile and found EventSensor>>wait2ms called from
>> places in EventSensor and indirectly via Sensor anyButtonPressed .
> imply that performance will be painful?
Not at all. Performance is quite good, we still use the same interface
in our products and the actual code is straight out of Cobalt. So on a
basic level the interface has production performance (what you do with
it in your application layer is a different problem of course :-)
The above comment related to the benchmark which was limited by using
Sensor anyButtonPressed in a tight loop - something you'd never do in an
actual product but which is handy for a quick benchmark.
More information about the Squeak-dev