Well if you look at the mpeg plugin you'll see that it renders to a  
chunk of bits that then gets displayed on
the window.

MPEGDisplayMorph>>openFileNamed: mpegFileName
see
frameBuffer _ Form extent: e depth: (Display depth max: 16).

The nnote
MPEGDisplayMorph>>nextFrame

which invokes
MPEGFile>>videoReadFrameInto: aForm stream: aStream

which drills down and invokes
primVideoReadNextFrameFor: aFileHandle into: aFormBuffer x: x y: y  
width: width height: height outWidth: aTargetWidth outHeight:  
aTargetHeight colorModel: colorModel stream: aStream bytesPerRow:  
aByteCount
	<primitive: 'primitiveMPEG3ReadFrame' module: 'Mpeg3Plugin'>

This primitive then has the responsibility for dropping bits in to  
aFormBuffer based on the input data that indicates start x/y  
width/height, scalling, color model etc.

Later on the morphic does
rawOn: aCanvas
	"Draw the current frame image, if there is one. Otherwise, fill screen  
with gray."

	frameBuffer
		ifNil: [aCanvas fillRectangle: self bounds color: (Color gray: 0.75)]
		ifNotNil: [
			self extent = frameBuffer extent
				ifTrue: [aCanvas drawImage: frameBuffer at: bounds origin]
				ifFalse: [self drawScaledOn: aCanvas]].


which enables it to be a true morpic so you can resize rotate etc etc  
and the primitive doesn't worry about those
details all it knew it had to construct a set of bits in aFormBuffer  
matching the expectations of the color model.

I must say when I showed this at the Squeak BOF a couple of years ago  
the audience cheered when I rotated the morphic and the
mp3 video continued playing at 35 degrees. However I viewed it as  
nothing special because once it's in the form then you can Squeak do
anything to it before displaying.

Ah when your Squeak VM crashs you know you've written outside that form.


Note the source code for the primitive is on sourceforge so you can  
trace the entire execution path
to understand how it works. The MPEG smalltalk software is in the  
3.2/3.4 stream.

Some people have written software to blit to the window directly, but  
then you lose the ability to interesting things and you
need to then manage issues like moving a morphic and interrelating back  
the coordinate change to the plugin etc. Quite a hassle.


On Wednesday, January 22, 2003, at 08:24  PM, Bagus Mahawan wrote:

>> On Thu, 23 Jan 2003 10:41:46 +0900 "Bagus Mahawan" <iwan at a-vip.com>  
>> wrote:
>>> Is it possible to implement a primitive that can manipulate pixels  
>>> inside
>>> squeak's window ? so that you can change the background image of the
>>> squeak's window, for example.
>>
>> Iwan,
>>
>> If all you want is to change the background for Squeak, you don't  
>> need to
> write any code. Point a FileList at a graphics file and choose 'open  
> image
> as background' from the menu.
>>
>> Cheers,
>> Bob
>
> Thanks Bob. But what I want is to make something like image processing  
> tool,
> where the GUI is developed on Squeak, while the image processing stuff
> itself is (hopefullly) done by primitives.
> So the first step is to find if there is any method for a primitive to
> render an image directly into a window on Squeak environment.
> For example, if you send a message
>   aForm doit
> (doit is a method that call the primitive)
> then the corresponding primitive will then periodically render an  
> image read
> from the file, one image in every 1 sec, for example.
> Is it possible ?
>
> Iwan
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===