[squeak-dev] Re: [Pharo-project] Offscreen drawing...

John M McIntosh johnmci at smalltalkconsulting.com
Sun Aug 23 17:46:17 UTC 2009


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:

> 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
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:   
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================







More information about the Squeak-dev mailing list