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 |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
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 |
Lawson English wrote:
> It would be very kool to have Squeak/Croquet able to render into SL the > same way. Smalltalk on a prim... This is actually utterly trivial. What you are looking for is in the SurfacePlugin. It allows to map external bitmaps into Squeak and to draw directly into it. The B3D engine uses this to do mixed-mode rendering in Direct3D; i.e., exposing the D3D rendering target to drawing operations in Squeak. Example code for the surface plugin can be found here: http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/ExampleSurfacePlugin/ The example uses a malloc()ed region of memory; you can use shared mem or whatever. Once you've created a form in this way all you need is to just BitBlt right onto it, or even better, just set it as Squeak's Display variable and all drawing will go onto it. Cheers, - Andreas |
Andreas Raab wrote:
> Lawson English wrote: >> It would be very kool to have Squeak/Croquet able to render into SL >> the same way. Smalltalk on a prim... > > This is actually utterly trivial. What you are looking for is in the > SurfacePlugin. It allows to map external bitmaps into Squeak and to > draw directly into it. The B3D engine uses this to do mixed-mode > rendering in Direct3D; i.e., exposing the D3D rendering target to > drawing operations in Squeak. > > Example code for the surface plugin can be found here: > > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/ExampleSurfacePlugin/ > > > The example uses a malloc()ed region of memory; you can use shared mem > or whatever. Once you've created a form in this way all you need is to > just BitBlt right onto it, or even better, just set it as Squeak's > Display variable and all drawing will go onto it. > > Cheers, > - Andreas > > hasn't been functioning well lately. Sighs. Hopefuly a few hours sleep will show me how to convert Helloworld to hello world, which is about all that needs to be done :-/ Lawson |
In reply to this post by Andreas.Raab
Given my mental issues, I'm not sure when I'll get this done (yes I
realize its trivial). However, Croquet/Cobalt on a prim will be really cool for a lot of reasons, IMHO and should be trivially doable. This is from an alpha VNC plugin for Second LIfe: http://www.flickr.com/photos/aimeethyst/3860441800/ If someone with even a modicum of intellectual stamina would like to do this, I can pretty much guarantee it will make Croquet/Squeak better known. I'm hoping that I can do it, but my mental health state isn't at its best and I sincerely see this as a project that will benefit both communities (Second Life and Squeak/Croquet/Cobalt) immensely, so anyone who wants to do it in their spare time will almost certainly get it done before I do. Lawson :-/ Andreas Raab wrote: > Lawson English wrote: >> It would be very kool to have Squeak/Croquet able to render into SL >> the same way. Smalltalk on a prim... > > This is actually utterly trivial. What you are looking for is in the > SurfacePlugin. It allows to map external bitmaps into Squeak and to > draw directly into it. The B3D engine uses this to do mixed-mode > rendering in Direct3D; i.e., exposing the D3D rendering target to > drawing operations in Squeak. > > Example code for the surface plugin can be found here: > > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/ExampleSurfacePlugin/ > > > The example uses a malloc()ed region of memory; you can use shared mem > or whatever. Once you've created a form in this way all you need is to > just BitBlt right onto it, or even better, just set it as Squeak's > Display variable and all drawing will go onto it. > > Cheers, > - Andreas > > |
Free forum by Nabble | Edit this page |