I have written a small Processing program that does a simple plasma animation. I have written two version of the program, as I was searching for a way to optimize it for better Javascript and Android performance. For the purposes of this question, however, I have been running both versions using the standard Java environment for Processing.
Although the code isn't terribly long, I will just post links to the code on here so that it doesn't clutter up this actual forum post. They links to the code files located on my Dropbox.
Now, I
expected the 2nd version of the code (or at least hoped) to have a significantly higher frame rate than the first version of the code, because in the 2nd version of the code I am using look-up tables to a higher degree.
In actuality, the 2nd version of the code
does get a marginally better frame rate initially, but then after about 1350 frames or so (and it is consistently around that time) the frame rate drops in epic proportions.
Here are a couple of figures showing what I am seeing. In the following figures, the
red line is version 1 of the code, and the
blue line is version 2 of the code (the version that uses more look-up tables and which I expected to have a higher frame rate).
Here is a 2nd figure where I zoom in on the problem area:
Does anybody have any idea what could be causing this, based off of looking at the code and the figures?
My machine is using an AMD Athlon X2 Dual Core processor, 1.5 GHz, 64-bit proc, with 3 GB of RAM, and running Windows 8.
Two possibilities I have come up with:
(1) For some reason the look-up tables in version 2 of the code don't entirely fit in cache, and so the processor has to continually swap out look-up tables in and out of cache, and this causes the frame rate to drop. If this were true, however, I would expect it to happen immediately, and not 1300 frames into execution of the program.
(2) The operating system is possibly dedicating more processing time to my app near the beginning of its execution, and then lowering its priority as execution time goes on, thus causing a drop in frame rate. But if this were true, I would expect it to be mirrored in version 1 of the code as well.
This is day 1 of working with Processing for me (this is what happens when I take a sick day from work
). I took a little bit of time to get Android Processing working on my machine, and ran into many of the same difficulties that many of you all have had.
Here is one more thing that I ran into, that some of you may be having trouble with. It stumped me for a bit, but I figured out what was the issue. This may not affect everyone. (FYI: I am using Processing version 2.0.1)
Processing seems to want to connect to an Android emulator on port 5566, and it doesn't seem to want to look at any other ports. You CAN change this in the preferences.txt file, but it seems to change it BACK to 5566 whenever you restart Processing. This may affect you if you have OTHER Android virtual devices in your AVD Manager. Depending on the devices you have in your AVD Manager, and what order they are in, you may need to edit preferences.txt so that it has the right port number of the AVD created by Processing.
For example, I already had a "Nexus One" AVD in my AVD Manager before I even installed Processing. For some reason, in order for Android Processing to work I had to do one of two things:
(1) First start my Nexus One AVD, which would be assigned to run on port 5554. Then tell Processing to build and run, and it would then start the Processing AVD on port 5566.
(2) Start the Processing AVD manually from the AVD Manager, which would then be assigned port 5554. I would then need to edit preferences.txt to use this port.
For some reason, simply having the Nexus One AVD in my AVD Manager blocked Processing from starting up its own Processing AVD unless I either (1) started up the Nexus One AVD first, or (2) started up the Processing AVD myself. When I deleted the Nexus One AVD, it solved this problem, and Processing was able to start up the AVD all on its own. But this may not be an option for everyone.
Hopefully this info helps out a few of you who are frustrated!