Question about <primitive:127>

Dan Ingalls Dan.Ingalls at disney.com
Sat Dec 9 23:09:49 UTC 2000


>I timed these two different pieses of code
>
>foo videoReadNextFrameInto: fum bits
>	width: fum width
>	height: fum height
>	stream: aStream.
>	fum displayAt: self videoMorph topLeft
>and 
>foo videoReadNextFrameInto: fum bits
>	width: fum width
>	height: fum height
>	stream: aStream.
>	Smalltalk specialObjectsArray at: 15 put: fum.
>      Display forceToScreen: fum boundingBox.
>      Smalltalk specialObjectsArray at: 15 put: Display
>and got 
>milisecond for the first: 
>87 78 107 127 92 120 90 88 114 107 89 91 115 83 96 87 144 82 98 88 89 104
>and for the second:
>59 63 60 61 66 73 92 79 65 64 71 106 64 63 73 80 66 83 69 63 66 66 76 77
>67 
>on a 320 at 240 video. 
>
>There seems to be some speed to pick up by avoiding BitBlt.

Karl -

While there is some speed to pick up here, it's at an awful cost -- basically your display will be out of sync with what's on the screen, and any normal piece of Squeak may mess things up.

If you must beat on the speed here (and I can understand why you want to), then certainly you should focus on bit depths being the same in your original form, Squeak's Display, and the OS's monitor setting.  If these are not the same, you can probably pick up more there than by eliminating a call to BitBlt.

Also, at this level of hacking (once the depths are the same), you should also know that in depths < 32 bits, BitBlt runs considerably faster if the source and dest are "aligned", that is that the source and destination leftXs are the same, mod the number of bits per word.  You'll see code that accomplishes exactly such a hack for 16 bit depths in MoviePlayerMorph>>position:.

If you are running BitBlt between equal depths, in "over" mode, with source and destination aligned, it will rip -- the inner loop just does word moves.  Let us know if any of the above optimizations improve your stats.

Also, I assume you understand that your first piece of code is actually doing BitBlt *plus* a forceToScreen, so the overhead brom BB is already down around 25% of the overall time in the "clean" version of your code.

Hope this helps.

	- Dan






More information about the Squeak-dev mailing list