Can Zaurus Handle This?

[wchall01]

I've completed an application that recieves streaming jpeg or MJPEG in a panel on the zaurus, in addition I have a few buttons which send various UDP packets when pressed.  The problem is that the SL-6000 using Jeode just can't seem to handle it.  Below I have details and different categories for which the problem might be attributed.  Any help or info would be very appreciated as there seems to be very little in the way of dev info for the SL-6000.

Processor/Video?

The problem I'm having seems to be an issue with the speed of the SL-6000's processor or video display rates.  I have set the speed of the MJPEG to as low as 5 frames per second and the zaurus still only shows like 1 frame update every 3 seconds or less.

Too many threads

I am using Jeode (evm) to run the application and the other strange thing I notice is what seems like nearly 25 different instances of Jeode (evm) that run when I invoke this application.  Granted, I have one thread which plays the stream in addition to the main frame, but why 25 instances?

Memory

Perhaps there is not enough application memory...How could I monitor this?

'top' for Zaurus

Even better is there an equivalent for 'top' for the zaurus so I could monitor cpu/memory?

PersonalJava or J2ME PP

So far I have not installed J2ME PP.  I am using Jeode/PersonalJava.  Would this have better performance and is the installation pretty straightforward for the SL-6000?

Out of my Mind?

Maybe the SL-6000 just can't handle this and I should be shipped to the coconut farm.


Any help, info, experiences, or hello's are welcome...

[Omicron]

Your'e going to have a tough time with video at 640x480....everyone I know runs video (movies, etc) at 320x240 and let the app stretch to the size of the screen.  Furthermore dropping every other frame (decimating by 2) will increase percieved speed and the missed  frames are not very noticable in almost any scene as the screen size is so small.

As for threads, check your JVM/EVM parameters...are you running with green threads (I don't know if the JVM supports that on the Z) but using -green should use one real thread and create multiple "virtual" java threads.

Memory usage would be greatly affected by multiple threads as well.  So changing the thread scheme to green may solve this too.

Java is not too fast at scaling, but you could write or use a native scaling library (maybe libSDL or some other) and let that do you scaling for you.  

By just transmitting 320x240 and every other frame, using native scale lib to scale UP should decrease your bandwidth and optimize the processor usage. Once these are complete, you can increase the KBits-per-second (or decrease the JPG compression) to achive better video that scales cleaner.  Either way, you'll have to use a lower resoultion than 640x480...of that I am sure.

I think this is do-able (not ready for coconut farm) but a total java soution may only be reasonable in a non-scaled 320x240 resolution.  

As far as TOP goes, I find SysInfo enough for me in Cacko Rom, but I imagine there is a linux solution that you can easily port to the Z....But remember top is resource intensive and will likely skew the data you are trying to analyze.  Simply logging some start.stop time metrics to a log file would prbably be alot less intrusive and many elegant solution exist to incorporate into your code (that you can toggle on and off easily) so that other perfromanace issues are easily resolved by turning on logging.

Hope this helps.

[wchall01]

Omicron,

Thanks for the very informative response.

The good news is that I'm not completely nuts and had no intentions of running 640x480 @ say 30 fps...my 1.6 p4 development laptop even chokes when I try that kind of silliness

I have been trying 320x240 from the start, default compression, 15 fps, then 10 fps, then lower...then lower...all with no success.

I am using the 640x480 real estate for additional buttons and textareas around the video canvas panel.

What I have learned today is that my application recieves a 320x240 jpeg, decodes, sends to g.drawImage() and keeps going.  The problem is that g.drawImage() is not updating the image.  my update() routine is written to prevent re-drawing the background of course and only calls repaint().

After testing this extensively I have found that if I give paint() (g.drawImage specifically) something like 2 WHOLE SECONDS then my image is updated.

Does this seem likely, that my entire bottleneck / delay is attributed to g.drawImage?  I mean, come on, I know the video card must be capable since this thing can play mini-movies, so perhaps the g.drawImage routine for the J2ME PP is really really slow.

I'm continuing to test this theory in more detail (How I dont know, but I'll figure something out)

Otherwise, "sysinfo" is good, thanks.  My app uses about 7 MB.

And the "-green" option did not work.  maybe its one of the more complex options i saw like "-NoSuperCrazyThreadsOfDoomXPDmjdkGGG" so I'll try to investigate those.

[wchall01]

Another update:

The real culprit is this bad boy:

if(!mediaTracker.waitForID(0,2000)) {  
        System.out.println("Failed to load image");
}

If i put a timer around it, it takes 1900 milliseconds to complete load a 320x240 jpeg.  Yay for 0.5 fps

I am using /opt/Qtopia/j2me/bin/cvm (J2ME PP 1.0) on the SL-6000, to reiterate.

If anybody knows how to speed this up please let me know.

Maybe there is a native library for writing to the graphics buffer.

If not, this means I have to scratch this whole application in Java and try Qtopia/C++.  Please NO!