Discussion Board

Results 1 to 4 of 4
  1. #1
    Registered User
    Join Date
    May 2005

    Undocumented Canvas repaint/paint deadlock in Nokia j2me

    my application was working fine on models other than Nokia, but used to freeze on Nokia phones. I was wondering why. With the emulator (Nokia Developer's Suite 2.2) I found out the following:

    Calling Canvas.repaint() requires somehow some 'work' of the system's Thread that is used for calling Canvas.paint(Graphics g).

    Suppose the following implementation of paint:

    paint(Graphics g){
    .....// do preparations
    ..........//paint the stuff

    Now, calling from my own thread
    will cause a deadlock, if paint() is currently executed and it is incidently in the code segment marked "do preparations"

    That's why I assume that repaint() somehow waits for the painting thread. Is this true, and if yes, why is this necessary? There is nothing about this in the j2me specs.

    Best regards,

  2. #2
    Registered User
    Join Date
    Mar 2004
    I have found something similar. In my case, the code that seemed to be blocking repaint was not in paint, but in a method called from keyPressed. I concluded that any blocked code within the event thread can prevent repaint from executing.

    This happened on the 7210 emulator and on the actual 6610 handset (series 40, MIDP 1.0). It did not occur in the default colour phone emulator of the Sun Wireless Toolkit.

    I agree that this looks like a bug. The repaint method is meant to do no more than generate a request to execute paint when convenient. I would have thought it should be possible to execute repaint at any time.

  3. #3
    Registered User
    Join Date
    Dec 2004
    Mexico City
    Hi, I had a similar problem, and I used serviceRepaints() method and it worked fine

    code in my Canvas class

  4. #4
    Regular Contributor
    Join Date
    Mar 2005

    I could be wrong, but if you're calling repaint() from within a synchronized(lock) block, and repaint itself has a synchonized(lock) bit of code, isn't that a "deadlock feature" cause synchronized blocks of codes should never call other synchronized methods?

    Your original method is holding the lock, and is calling another method requiring that same lock. But because you are waiting for it and thus never release it, that causes the deadlock???

Posting Permissions

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