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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================