×

Discussion Board

Results 1 to 10 of 10
  1. #1
    Regular Contributor
    Join Date
    Jun 2009
    Location
    Tel-Aviv Israel
    Posts
    410

    performance on phone

    hey guys,

    Is this a well known fact that the painting of the buffer on the screen is the most consuming time factor in the paint update loop?
    Thanks,
    Adam Zehavi.

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: performance on phone

    I would say that's generally true. I've seen as much as 90% of time taken by painting.

    Graham.

  3. #3
    Regular Contributor
    Join Date
    Jun 2009
    Location
    Tel-Aviv Israel
    Posts
    410

    Cool Re: performance on phone

    so if I would like to maintain maximum efficiency in the paint, I would only flush the regions of the top tree components...

    Thanks you again Graham.
    Thanks,
    Adam Zehavi.

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: performance on phone

    Two things (usually) cost you time in paint().

    First, the number of pixels you paint. Obviously, every time you copy a pixel to a buffer image or to the screen, it takes a small amount of time. Probably, you're going to push thousands, or more likely tens or hundreds of thousands of pixels for every frame, so that small amount of time adds up.

    Second, there is an overhead every time you invoke a method - which can be quite large, especially for non-private instance methods. Painting a small number of large images tends to be faster than painting a large number of small images - same number of pixels in fewer method calls.

    If you're using a Canvas, and overriding paint(), then you must paint every pixel in the Graphics object's clip region. So that imposes a lower limit on the number of pixels you have to paint.

    Using a buffer image (or a GameCanvas, which creates a buffer image for you) allows you to update just the parts of the image that you know have changed. This is effective when only a small part of the screen changes in each frame.

    Graham.

  5. #5
    Super Contributor
    Join Date
    Mar 2008
    Location
    The Capital of INDIA
    Posts
    4,328

    Thumbs up Re: performance on phone

    Quote Originally Posted by grahamhughes View Post
    Using a buffer image (or a GameCanvas, which creates a buffer image for you) allows you to update just the parts of the image that you know have changed. This is effective when only a small part of the screen changes in each frame.

    Graham.
    Hey guy's just joining this thread... and excuse me if I have bothered you guy's..
    Well Graham how this above quoted lines works in details.. could you please explain.. ?


    For the bold and italic lines how can I know that which is the portion/part of the scree that is just changed...?
    Please explain ...what are the technique for this..?
    Thanks with Regards,

    R a j - The K e r n e l


    Join Delhi-NCR Nokia Developer's Community,

  6. #6
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: performance on phone

    You determine this from game logic.

    For example, if your game is something like Bejeweled, then as you move the cursor around the grid, only two squares on the screen change (the one where the cursor was, and the one where it is now). When you swap two jewels in the grid, again only those two squares change.

    On very low memory phones, you can't take advantage of this: you must paint the entire screen every time, no matter what.

    If you have enough memory to create an Image the same size as the screen, then you can just update those parts of that image that you know will have changed, then paint the entire image to the screen (in the paint() method of a Canvas, or by calling flushGraphics() on a GameCanvas).

    For games that have scrolling backgrounds, this can be much harder. Sometimes you need a buffer image larger than the screen to do this effectively. Exact strategies for paint opimization will depend on the specific type of game.

    In some cases, the amount of logic needed to work out which parts to repaint will take so much time, and actually find that you need to repaint 90% of the screen, that the time saved is less than the time taken by the logic, so you might be better just to repaint everything.

    Graham.

  7. #7
    Super Contributor
    Join Date
    Mar 2008
    Location
    The Capital of INDIA
    Posts
    4,328

    Thumbs up Re: performance on phone

    Quote Originally Posted by grahamhughes View Post
    You determine this from game logic.
    If you have enough memory to create an Image the same size as the screen, then you can just update those parts of that image that you know will have changed, then paint the entire image to the screen (in the paint() method of a Canvas, or by calling flushGraphics() on a GameCanvas).
    Graham.
    Thanks for entertaining the query, Graham..
    Let me do some more analysis on this and give the time to ask the any other query to the original starter of the thread...I will come again for any further questions.

    Thanks..
    Thanks with Regards,

    R a j - The K e r n e l


    Join Delhi-NCR Nokia Developer's Community,

  8. #8
    Regular Contributor
    Join Date
    Jun 2009
    Location
    Tel-Aviv Israel
    Posts
    410

    Question Re: performance on phone

    Thank you for the info Graham,

    but here is the thing, I did not do that of a game point of view I was forced into it cause of performance reasons, here is what I did:

    my canvas has a non buffer container, one and only container the canvas can have, which I use to hold buffered top components, the only thing I have to do to flush these regions is
    PHP Code:
    for(int i=0;i<topContainer.size();i++)
        
    flush(topContainer.getComoponent(i).getBounds()) 
    not to many calculation needed, the design is already applied and proved to be efficient enough after testing, to indicate to me that with more then 10 animations, if I shrink the size of the flushing region to (100,60) the execution time is less then 2 ms on both N97 and W995, problem is as I mentioned in my other thread, as soon as I flush the entire screen of both phones, or even less performance decrease rapidly, the N97 would not be able even to flush an empty screen with 20 fps not to mention with a game paint and update loop with it, so I was forced to define regions to flush.

    So I was looking for an elegant solution how not to keep my screen empty yet to get maximum efficiency on both small screen devices and larger screen devices, so I've decided to define a background Image for an application and paint it only every now and then to the screen, so it would not be empty, and to flush only the regions of the most top buffered components...

    What do you think?
    Last edited by TacB0sS; 2010-05-03 at 21:41.
    Thanks,
    Adam Zehavi.

  9. #9
    Regular Contributor
    Join Date
    Jun 2009
    Location
    Tel-Aviv Israel
    Posts
    410

    Re: performance on phone

    after long sitting up till 5 hours ago, and investigating a bit, I can tell you that the reason for these weird values that I get are because the repaint method of the canvas was not executed because it didn't finish the previous paint cycle. I fixed my code to compensate for this issue in the calculation, yet still the N97 persists to perform very poorly 34ms/frame to compare with W995 5-6ms/frame, doesn't any one else do these tests? is this not a valuable information for developers whom develop for N97...

    Thanks for all your help guys.

  10. #10
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: performance on phone

    Yup, most phones are performance tested at JBenchmark.com. There are benchmarks for the W995 and the N97. Note the difference in "JBenchmark 1.0" scores (3714 for the N97 vs. 7206 for the W995). A big part of the difference will simply be the screen size... the N97 is pushing around three times the number of pixels.

Similar Threads

  1. OMA DRM media transfer using PC to Phone using USB
    By venky123 in forum Digital Rights Management & Content Downloading
    Replies: 1
    Last Post: 2008-08-13, 03:02
  2. Replies: 2
    Last Post: 2008-05-17, 23:29
  3. The Nokia 9210i is the shittiest nokia phone ever!
    By awyeah in forum General Development Questions
    Replies: 2
    Last Post: 2007-10-18, 10:31
  4. 7610 Contacts - Formatted Phone Numbers
    By padlon in forum General Development Questions
    Replies: 2
    Last Post: 2004-11-12, 18:02

Posting Permissions

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