Offscreen drawing...

Is there a way to render into an offscreen buffer where the actual host
hardware's address is specified? I realize that at the level of
implementing the hooks for the VM, this must be possible, but is it
[easily] possible to redirect the memory space that Squeak renders to at
runtime, rather than during creation of the VM?

I'm trying to understand how one might use the shared memory space of
Second LIfe's media plugin to be the drawing region of a regular Squeak
Smalltalk workspace/drawing window. Being able to have fully active
Smalltalk-on-a-prim in SL would rock, especially if you could have a
choice of whether to work directly with the in-world rendering or with
the normal Squeak window's rendering.


The plugin can live in a separate process and communicate higher level
events via sockets and share memory for rendering so its not necessary
to have a fully standalone plugin. From the SL side, you could
conceivably have a regular Squeak development environment with the added
ability to use a specified hardware buffer instead/in addition to the
regular Squeak window. Sorta like what seaside sorta does, but without
the overhead of rendering via html.


Lawson



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lawson, the browswer plugin logic does this type of interaction.

The x11 unix running as a separate process draws to the X11window of  
the browser process, and
uses pipes to coordinate data, movement of UI commands file upload/
download requests.

The Window's version does a similar things I believe.

The macintosh carbon VM (non x11 based) is a bit more complex since it  
can't share the drawing space
of the browser task, it setups a shared memory space that is the  
backing store for squeak drawing, and for a semaphore
Again unix pipes are used to coordinate UI commands but also draw  
commands back to the browser.
The semaphore is used to regulate drawing between the VM and the  
browser process since the VM can
generate drawing faster than the browser can render it on dual CPU  
machines.

I'm not sure if this is what you are looking for?  Squeak also has the  
concept of off screen forms  (squeak surfaces) where you
can render a form into a chunk of memory, or have something else  
render the visual data into that memory.

The Quicktime plugin in the macintosh plugins source sets up a surface  
that quicktime draws into, then when quicktime renders the image and  
does a callback our callback routine signals
a semaphore that then triggers a squeak process that draws the Form to  
the squeak display.  The reverse is in Squeak you draw to the Form it  
renders the bits into the memory space allocated outside of the squeak  
oops space.



On 23-Aug-09, at 1:34 AM, Lawson English wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

John M McIntosh wrote:
> Lawson, the browswer plugin logic does this type of interaction.
>
> The x11 unix running as a separate process draws to the X11window of  
> the browser process, and
> uses pipes to coordinate data, movement of UI commands file upload/
> download requests.
>
> The Window's version does a similar things I believe.
>  

Thanks John. I'm trying to understand how things fit together. It
*looks* simple but for some reason I'm not grokking it.


BTW, here's a experimental VNC SL plugin someone is working on:
http://www.youtube.com/watch?v=rxUrU9DPMjA&hd=1


It would be very kool to have Squeak/Croquet able to render into SL the
same way. Smalltalk on a prim...


Lawson

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project