Josh Gargus wrote:
> Very cool, nice work!
>
> If it turns out that you need more CPU cycles, you might try using PBOs to asynchronously read the pixels... when you call glReadPixels(), the function does not return until the pixels have been completely read, and while you're waiting for the pixels to cross the PCI-E bus, Squeak isn't doing any processing.  If you're reading back 30fps at 5ms per frame (according to your measurements below), you're sitting idle about 15% of the time.
>
> Search for "Asynchronous glReadPixels:" in the PBO extension spec (http://www.opengl.org/registry/specs/ARB/pixel_buffer_object.txt).  Google will turn up many more tutorials.
>
> It probably won't be your top priority right now, but I wanted to ensure that you're aware of the option.
>
> Cheers,
> Josh
>
>   

Thanks. I was aware of PBOs and the like but didn't want to get into 
them until I got something simple working. Am I misunderstanding 
1000x1000x1000x4/6?

I get more like 160fps x 1megapixel raw blitting speed which sounds fast 
until one realizes that not much else is going on period.

BUT it is fast enough to justify things  like testing the rendering of  
cobalt using one instance of squeak while displaying/manipulating using 
another if you have a multi-core system.

What happens to parallel processing speeds in squeak when shared memory 
is used instead of streaming over sockets ala teatime?



>
> On Feb 11, 2010, at 1:54 PM, Lawson English wrote:
>
>   
>> Lawson English wrote:
>>     
>>> So,  I can now draw using squeak opengl calls and they are now accessible in another process.
>>>
>>>       
>> Benchmark:
>>
>> Time millisecondsToRun: [1000 timesRepeat: [
>> ogl                     "read pixels into my buffer"
>>   glReadPixels: 0
>>   with:  0
>>   with: 1000
>>   with: 1000
>>   with: ogl imagePixelFormat32
>>   with: ogl imagePixelType32
>>   with: xData.
>> ]]   => 5930
>>
>>
>> :-)
>>
>>
>> Lawson
>>
>>     
>
>
>