×

Discussion Board

Results 1 to 8 of 8
  1. #1
    Registered User
    Join Date
    Aug 2006
    Posts
    4

    Is MIDP2.0 over Symbian OS slow?

    I have been trying to develop a game on a 3230 (S60 2ED) and the game paits very slowly on the device whereas on other non-Symbian NOKIA devices it is very fast.

    Also, I have found out that the more the frames in a Sprite, the slower it paits it when you transform it.

    Does anyone suspect why?
    I mean, what is the proper way to implement a Java game for S60? Do I have to use int[] RGB and drawPixels() for the sprites or what?

    E.

  2. #2
    Super Contributor
    Join Date
    Dec 2005
    Location
    Europe/Poland/Warsaw
    Posts
    1,699

    Re: Is MIDP2.0 over Symbian OS slow?

    hi epolitakis,

    use JBenchmark to get comparable results:
    http://www.jbenchmark.com/phonedetails.jsp
    between that device and other you have used
    that review mentions some slowness of j2me on that device:
    http://www.mobile-review.com/review/nokia-3230-en.shtml,

    regards,
    Peter

  3. #3
    Registered User
    Join Date
    Aug 2006
    Posts
    4

    Re: Is MIDP2.0 over Symbian OS slow?

    It's getting more bizzare..

    Intro: cycle = tick + draw + flush

    If I use pure MIDP2.0 then when the Sprite is facing left (no transformation), the cycle is arround 71 ms and when the sprite is facing right (transforms), the cycle jumps to 290 ms, from which major time is consumed by flush!!

    Painting to the buffer is fast enough (arround 10 ms) tested on a 3230 but when the buffer is painted to the Graphics passed to the paint() method of GameCanvas / Canvas / FullCanvas (tested with all of them) then the flush is taking ages.

    I started to research it and found out that if the MIDP2.0 Sprite frames image is not transparent, the tick drops to 45 ms for left and 60 for right (still transformation is takes time), but the game speed is acceptable.

    Also found out that the delay in the transformation has to do with the number of frames in the image - the more frames in the image the longer it takes to transform.

    I tried to use DirectGraphics everywhere in the code but the problem remained. Actually, it got worse when I tried to convert the the paint(Graphics g) object to a DirectGraphics; MIDLet crashed with OutOfMemory Exception.

    I tried to load all my images the NOKIA way, using DirectUtils, just in case I had to apply NOKIA graphics capabilities throughout the MIDLet, but nothing happened.

    I also tried to use drawPixes-kind of API from both MIDP2.0 and NOKIA UI just in case, nothing happend again, the delay remains

    Ok, I am convinced the problem lies with the image transparency..

    I guess the question is how to use standard MIDP (or anything else) to paint a sprite with transparency on a S60 / 3230 Symbian OS NOKIA.

    Elias

  4. #4
    Registered User
    Join Date
    Aug 2006
    Posts
    4

    Re: Is MIDP2.0 over Symbian OS slow?

    More results, I have managed to use just MIDP2.0 and no NOKIA UI libs and got the performace down to 40ms!!

    Aparently in my thread's run() method I was using t.yeld() and I changed it with wait(1);

    I suspect that yelding a thread might be causing some sort of service repaints because the actual performance counter that was reduced is flush.

    However, even though I have no more performance differencies when the sprite is facing left or right (transofrmations), the gameplay is not perfect - far from perfect I would say and it is related with the keypad where I use keyPress / keyRelease events.

    Also, I will try to use my own implementation of MIDP2.0 instead of the device's support because I suspect that the TiledLayer is not optimized (meaning it redraws all cells and not just the visible ones) and Sprite collision detection seems to be slow when the sprite is transformed.


    More investigation on the way...

  5. #5
    Registered User
    Join Date
    Aug 2006
    Posts
    4

    Re: Is MIDP2.0 over Symbian OS slow?

    Ok, final results.

    For starters, MIDP2.0 over Symbian is not slow!

    It all depends on how you write your code and especially threading. I recommend using wait() statements for synchronizing the core thread rather than yeald() and fewer synchronized(){} blocks and threads as possible. It seems that for Symbian OS NOKIA phones (even for the latest N73), threads are bad.

    Now, regarding graphics, I have found out that indeed for some S60 devices there are two major performance issues: 1) with Sprite transformations when the frames image is too big and 2) with TiledLayer when there are too many cells (say 500*500).

    Why? Because the Sprite class is calling internally drawRegion() which seems to have bad implementation for transformation, and as for TiledLayer it repaints at each cycle all cells and not only the visible ones. I cannot prove it, but I can measure it and this is the only explenation I can provide.

    How to deal with it? Well, I have painfully rewrote the entire gaming classes of MIDP 2.0 and use them insted, only to realize that I got severe memory and performance optimizations beyond expectation. Apart from several obvious optimizations that were missing the MIDP2.0 implementation, I also added an Image Manager, which reduced memory requirements of the MIDLet dramatically.

    Consider a Stage with 100 Sprites! One of them is the Player Sprite and rest 99 are the enemy sprites. With standard MIDP2.0 implementation each Sprite keeps internally its own copy of the Frames Image. Now, if your code is read stream / create sprite, then you have different instances of the same image read each time for each sprite resulting to 99 same images in the memory!

    I suspected that if you read an image and use the same image for creating 99 sprites, then the memory would only increase by the footprint of the instantiated objects and not by the ammount of 99 copies of the original image. Well, it seems to be an erroneous assumption because on our test device 3230 the memory increased and on SE S700i it worked as assumed. Meaning, on some implementations a reference to the image is used, whereas on others the image is copied. Which ones though?

    What I decided was to cache each Sprite imagestrip (frames) in my Image Manager and also, cache the current frame image of a Sprite at local Sprite level. The frame is cached transormed if nessesary inside the paint() method of the Sprite and the reason for doing so is that if you think about it, in the next cycle you most likely will use that image for collision detection, so its good to have it handy rather than aquire it again a few milliseconds later.

    When the time comes for a Sprite to paint the current frame, it asks Image Manager to provide the original imagestrip, passing an image ID. I am also investigating whether the image manager should return the actual frame image transformed or not... Also, for the Image Manager I use a Hashtable and I am wondering whether to avoid it and do a straight scan on an array. I suspect that it would be much faster for a few tens of images that are actually kept.

    Also, Enemy Sprites 90% of the gameplay time are facing to one direction (left or right for platform games) whereas the Player Sprite is more flexible. So, based on this assumption, there is no need to optimize sprite transformations for enemy sprites whereas we could provide serious optimizations to the Player Sprite by caching at Sprite-level each transformed frame image. Initially I assumed that transormations are slow for large images and I tried to break and cache each frame image in an array but I observed 2ms delay on 3230 when the frame was being painted transformed. So I decided to cache them pre-transformed. Note that there was no delay observed when calling drawRegion() for painting a non-transformed frame nomatter what the size of the imagestrip was.

    Thus, I decided to actually cache two things for the player Sprite: the entire non-transformed frames image and the individual transformed-images of each frame, and voila! No delays whatsoever and blilliant performance.

    Synoptically, the image caching implemented were:
    1) Sprite imagestrip in the Image Manager - Memory Optimization
    2) Current transformed frame in the Sprite - Tick Performance Optimization
    3) Transformed frames in the Sprite - Paint/Flush Performance Optimization

    Also, I made some simple optimizations on the TiledLayer and it now paints only the cells that are on-screen and not the entire surface. That sure gave me some more milliseconds.

    With some serious optimizations in my code regarding inexpensive ticking (I tick an object when it is on-screen), I now have: Cycle = Tick + Paint + Flush = 0!!! + 2 + 30 = 32 ms on a NOKIA 3230. Note that in tick is also included the time for collision detections! (which I had to painfully rewrite due to transofrmations...).

    Even though it seems that I use more memory for the player sprite, I have actually saved more memory by having the image manager!! Ok, for Symbian OS phones, due to the dynamic allocation there can be no accurate nor real numbers when calling Runtime.freeMemory / totalMemory but I sure saw some 70% decrease on a stage with 100 sprites and also, it loads faster because I do not read the image again and again from the stream.

    I hope my troubles and the solutions I describe might help others in your quest for quality games compatible with NOKIA Symbian phones.

    Just for Appendix some numbers:

    All tests were performed on NOKIA 3230 but memory tests were performed on Sony Ericsson S700i and W810. Also tested on N73 with similar results.

    With pure MIDP2.0 and Thread.run using yeld();
    C = T + P + F = 0 + 15 + 71 (sprite facing right - no transform)
    C = 1 + 15 + 290 (sprite facing left - horizontal transform)
    Memory: aprox. 400K (tested on Sony Ericsson S700i/W810)

    With pure MIDP2.0 and Thread.run using wait(1);
    C = 0 + 10 + 35 (no transform)
    C = 1 + 10 + 40 (transform)
    Observed GC like behavior - small latency and lags felt in the keypad
    Memory: aprox. 400K (tested on Sony Ericsson S700i/W810)

    With MIDP2.0 replacement:
    C = 1 + 5 + 35 (no transform)
    C = 1 + 5 + 35 (transform)
    Memory: 270K (tested on Sony Ericsson S700i/W810)

    Hope I helped.

    Elias
    http://www.mobilefx.gr

  6. #6
    Super Contributor
    Join Date
    Dec 2005
    Location
    Europe/Poland/Warsaw
    Posts
    1,699

    Re: Is MIDP2.0 over Symbian OS slow?

    hi Elias,
    I was reading what you have posted here and that is really useful for people learning some optimizing concepts - like me ;)
    regards,
    peter

  7. #7
    Registered User
    Join Date
    Jul 2006
    Location
    legazpi city, philippines
    Posts
    22

    Re: Is MIDP2.0 over Symbian OS slow?

    I am not sure about this but I think only S60 devices are slow. Correct me if I'm wrong.

    regards,

    noobprogrammer
    http://sonusdream.blogspot.com/

  8. #8
    Registered User
    Join Date
    May 2005
    Posts
    76

    Re: Is MIDP2.0 over Symbian OS slow?

    This is a most interesting thread I've read here.

    The buggy drawRegion() on S60 2nd was known to me, but did not know that Sprite uses it. But what shocked me was the fact that Sprite caches frames. Is a common thing, or specific to S60 2nd, or all S60, or even all MIDP implementations? The javadoc for Sprite is kind of encouraging a developer to use Sprites for there might be hw acceleration or something...

Similar Threads

  1. Current Symbian Development Opportunities...!!
    By mobile2004 in forum Symbian
    Replies: 0
    Last Post: 2005-01-17, 17:58
  2. Replies: 0
    Last Post: 2004-05-21, 11:16
  3. Replies: 2
    Last Post: 2004-05-08, 09:09
  4. Global Symbian Development Opportunities *High Importance*
    By sara.lindsay in forum Symbian Tools & SDKs
    Replies: 0
    Last Post: 2004-05-07, 12:17
  5. Replies: 0
    Last Post: 2004-05-07, 11:45

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •