[squeak-dev] Offscreen drawing...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Offscreen drawing...

LawsonEnglish
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



Reply | Threaded
Open this post in threaded view
|

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

johnmci
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
=
=
=
========================================================================





Reply | Threaded
Open this post in threaded view
|

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

LawsonEnglish
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

Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

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

LawsonEnglish
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
>
>
Thanks Andreas. I'd already seen that but for some reason the brain
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

Reply | Threaded
Open this post in threaded view
|

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

LawsonEnglish
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
>
>