 |
Author |
Topic: processing itself (Read 355 times) |
|
justo
|
processing itself
« on: Mar 31st, 2004, 3:02am » |
|
sorry, dont know if this is the right place to put this, but does anyone know how processing posts the pixel array onto the screen? looking here
http://mrl.nyu.edu/~perlin/experiments/puff/PixApplet.java
in the only similar example i can find, ken perlin uses a MemoryImageSource as the image producer to interface between his pix array and an Image...which he paints to the screen in the update() method by calling
g.drawImage(im, 0, 0, null);
now i know that you guys are eventually going open source so hopefully this isnt a state secret, but professor perlin's applet was made to be java 1.1 compliant, so i was thinking maybe you guys have some newer ideas.
anyways, just curious. thanks,
justo
|
| « Last Edit: Mar 31st, 2004, 3:44am by justo » |
|
|
|
|
justo
|
Re: processing itself
« Reply #1 on: Mar 31st, 2004, 3:43am » |
|
on inspection of running methods (sorry to snoop), it appears that processing does use a MemoryImageSource...but it blits to screen significantly faster than perlin's applet (well, relatively significantly faster...perlin's is still pretty fast).
anyway, sorry for the rambling to the self, just giving you a headstart on your explanation
|
|
|
|
|
fry
|
Re: processing itself
« Reply #2 on: Apr 1st, 2004, 4:02am » |
|
yup, that's all it does.
there are a couple tiny tweaks you can do to make it faster, i.e. that you use a 32-bit DirectColorModel explicitly, and some fiddling with the thread timing (mac vs. pc vs. linux handle this differently) to get it at maximum speed. the memimgsrc is also set for full buffer updates and setAnimated(true).
fwiw, code exported with processing is entirely 1.1 compliant as well.. unless of course you explicitly use >1.1 features.
|
|
|
|
|
justo
|
Re: processing itself
« Reply #3 on: Apr 1st, 2004, 4:59am » |
|
cool, thanks for the reply.
the reason i thought it was so much faster, by the way, is that (it appears) processing is calling its update() method manually, as opposed to letting awt get to it when it wants to. so the blitting was the same speed, just happening elsewhere in the call hierarchy. does this give any benifits? im thinking speed, page tearing, etc...from a quick think through i would guess page tearing would go down (eliminated?) but the loop() rate would go down as well...though not significantly.
again, thanks for the info.
|
|
|
|
|
fry
|
Re: processing itself
« Reply #4 on: Apr 2nd, 2004, 5:05pm » |
|
right, it's a bit of a balance between those things.. and it's more problematic because of the differences between the different platforms (mac, windows, linux). windows gives me a lotta control for controlling updates, the mac gets a bit more uppity as their vm seems to be more heavily threaded, which can cause some kookiness and requires extra care for synchronization.
the Toolkit.sync() call forces update() and paint() to be called immediately, so that speeds things up a bit.. but for instance on the mac, if it doesn't quite want to sync yet, it might burp for a split second before it does things.
these issues improved between 68 and 69 but there are still a couple of minor kinks to work out. it's not as simple with the newer (1.2+) versions of java.. 1.1 it was so easy to just force the update
|
|
|
|
|
|
