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

Cheers,
   - Andreas