Dan Ingalls wrote:
> 
> >Attached is a version of MPEGPlayer2 and MPEGPlayerMorph that
> >lets one reset the size of the video/morph. You can actually
> >delete the video/morph, and video will show up anyway :-)
> >
> >It uses
> >form displayAt: morph topLeft.
> >instead of
> >self changed
> >to update.
> 
> Why is this?  I had a similar hack in Squeak's MoviePlayerMorph, and took it out because it won't behave as a proper morph otherwise (ie it can't be put behind other things while playing).
> 
> My hack was for speed, and I suspect yours is as well.  But if you are careful about things the overhead of the change/drawOn: cycle is small compared to the time to Blt to the display.  Even if you put things on top of it forcing the blt to be done in pieces, the savings in area painted usually makes up for the rectangle managment overhead.
> 
> What was important in the MoviePlayer case was that changed got sent to the right object (the imageMorph that held the actual frame form) so that only the frame rectangle got invalidated.  Have you tried this, and is it really slower?  Is the problem a BitBlt mode problem -- then you could mess with drawOn:?
> 
> Just curious.  It seems a shame to have so much working so well and then not be a well-behaved morph.  I have a feeling we could have the best of both worlds.
> 
>         - Dan


All my hacking is from observing some clips with a running timecode
on them so each frame can be seen or at least you get a sence of the
flow. The clips I have are really small (160 @ 120 at 25 frames a sec.)
By observing the two different  ways I can see a sligthly higher
framerate by using displayAt:. I don't know why yet. 
The morph has a drawOn: with a form over
instead of form paint implemented so it should be fast .  I'll take
a deeper look into it and see what issues are causing this.
A well behaved morph is what we want :-)

Karl