The long way, and how to avoid it.
Hi all,
Here is a problem that appeared on the #squeak irc channel today (22 Feb 2008) Matthew solved it brilliantly as I was plodding with speed ups I knew I could do. Below is a series of modified examples with time profiles (from an old turn of the century iMac.) It illustrates how to have fun with optimizations and iterations on a project. The intermediate steps might prove useful in other contexts.
[ | img col x y | img := ImageMorph defaultForm asFormOfDepth: 32 .
y := 0. [y < (img height)] whileTrue: [ x := 0 . [x < (img width)] whileTrue: [ col := (img colorAt: x@y) . img colorAt: x@y put: (TranslucentColor r: (col red) g: (col green) b: (col blue) alpha: 0.7). x := x + 1. ] . y := y + 1. ] .
img asMorph openInWorld. ] timeToRun "1152"
"-------"
[ | img col x y | img := ImageMorph defaultForm asFormOfDepth: 32 .
y := 0. [y < (img height)] whileTrue: [ x := 0 . [x < (img width)] whileTrue: [ img colorAt: x@y put: ( (img colorAt: x@y) alpha: 0.7). x := x + 1. ] . y := y + 1. ] .
img asMorph openInWorld. ] timeToRun "930"
"-------"
[ | img | img := ImageMorph defaultForm asFormOfDepth: 32 .
(0 to: (img height)) do: [ :y | ( 0 to: (img width)) do: [ :x | img colorAt: x@y put: ( (img colorAt: x@y) alpha: 0.7) ] ] .
img asMorph openInWorld. ] timeToRun "934"
"-------"
[ | img picker poker | img := ImageMorph defaultForm asFormOfDepth: 32 .
[ | img picker poker transColor | img := ImageMorph defaultForm asFormOfDepth: 32 . picker := BitBlt bitPeekerFromForm: img . poker := BitBlt bitPokerToForm: img . (0 to: (img height)) do: [ :y | ( 0 to: (img width)) do: [ :x | transColor := ( Color colorFromPixelValue: ( picker pixelAt: x@y) depth: 32 ) alpha: 0.7 . poker pixelAt: (x@y) put: ( img pixelValueFor: transColor ) ] . ] .
img asMorph openInWorld. ] timeToRun "376"
"-------"
[ | img destForm | img := ImageMorph defaultForm asFormOfDepth: 32 . destForm := img allocateForm: (img width)@(img height). destForm copyBits: img at: 0@0 translucent: 0.7. destForm asMorph openInWorld. ] timeToRun " 4"
"-------"
wiz 2/22/2008 17:11
Ok. what do we have here.
Here are five examples of the same behavior. A 32 bit form is obtained and processed to obtain a 0.7 translucent version of the same form. The translucent form is displayed on the screen.
The first example (I modified the img to avoid an external file reference.) was submitted by a user who noted it was slow. ( If he was using a substantially larger picture he would have noticed an even bigger delay. The first image takes about a second per postage stamp sized picture on my old iMac. )
The second pass optimizes some of the innerloop by not breaking the color down into its componects but just making the whole color transparent. This saves about 25% of the time.
The third pass simplifies the code by enumerating the height and width implicitly. This doesn't save any time ( it may even take a tad longer). But it eliminates several lines of code. Which makes what is going on clearer.
The fourth pass optimizes the picking and poking of pixels by seting them up explicitly. This means we are back to explicitly turning pixels to colors and back again. The reward for our efforts is a further 60% reduction in time.
Now there should be some way to just have a form copy itself and pick up a fixed alpha along the way. I just haven't gotten smart enough to know how.
Ah. Matthew has pasted it as an annotation to imaginators original paste. http://paste.lisp.org/display/56338#2
Giving us a fifth example.
Letting bitBlt do all the work is clearly a winner. A 99% speedup.
Next step is to see why .pngs take so long to load. And that is left as a execise for the reader.
Yours in curiosity and service, --Jerome Peace
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ