 |
Author |
Topic: Example of porting from existing applet (Read 2492 times) |
|
Glen Murphy
 
|
Example of porting from existing applet
« on: Nov 8th, 2002, 4:08am » |
|
I went back and ported one of my older Java experiments to proce55ing just to see how long it would take (20 minutes).
http://bodytag.org/nav.php?u=maya1/
The Java source and p5 source are both linked off the page above. The applet running is the straight Java version. The proce55ing version does run slower, probably due to having to deal with both my pixel buffer and its own.
|
|
|
|
|
fry
|
Re: Example of porting from existing applet
« Reply #1 on: Nov 8th, 2002, 7:49am » |
|
thanks for posting this. it's useful to see the comparison.
from a quick glance, a couple of tweaks that might be useful to note, since you mentioned the speed thing.. these are applicable in lots of cases and this is an easy example to point them out:
- you can access p5's pixel buffer directly. this is one of the joys of p5. it's an array of ints called 'pixels'. the global vars 'width' and 'height' tell you its size. so rather than storing your own, you may as well just write directly into it. the joy part is that unlike in regular java apps, you can draw primitives and then start playing with pixels in this manner.
- if you don't need to blank the screen each time around (which just fills pixels[] with the background color) use noBackground() inside setup
- if you're iteratevely assigning lots of values into the pixel array, setPixel() is gonna be slower than necessary. just use pixels[] and index right into it. wee! setPixel() is there for easy access, not speed.
- random(WIDTH) is shorter and simpler and does the same thing as random(0, WIDTH)
- speedwise, why not use floats instead of doubles? they're generally much faster, and the extra precision is almost never needed for small on-screen works like these. (doubles need two ops with the vm to push a 64 bit number.. more painful on some machines than others)
- as an aside, i find it tends to be a good idea to set the high bits of a java color (0xff000000), because alpha didn't work in jdk 1.1, and MemoryImageSource will sometimes cause inconsistent alpha values to flicker.
- and if you're feeling really anal, i have a feeling that WIDTH*HEIGHT in your loop won't (necessarily) be optimized as a constant (depends on the compiler), and that WIDTH*HEIGHT will be evaluated each time you go through the loop  even if you set it to static and final, because of the inconsistency with compilers/jits i tend to prefer just to have another var called "COUNT" or something like that.
hope that helps..
|
|
|
|
|
Glen Murphy
|
Re: Example of porting from existing applet
« Reply #2 on: Nov 8th, 2002, 9:14am » |
|
Thanks Ben, I've updated the source on the site with these changes.
Double super extra thank-you on the tip regarding the pixel buffer - it's what I've been missing in proce55ing.
|
|
|
|
|
Dimitre
|
Re: Example of porting from existing applet
« Reply #3 on: Nov 8th, 2002, 2:27pm » |
|
pixels array is very fine, and is the same principle of the java tinyPTC library http://www.gaffer.org/tinyptc/
really amazing
|
|
|
|
|
fry
|
Re: Example of porting from existing applet
« Reply #4 on: Nov 8th, 2002, 4:23pm » |
|
yep, the model we use for the pixel buffer is identical to the one in tinyptc.. so if you use noBackground() and just play with pixels[] directly, it should have the same capabilities & be the same speed.
|
|
|
|
|
|
