[zivgr]

I have one Canavs in my application and I update from time to time an Image on it.
The problem is that sometimes after the update, the last image is gone (which is what I want) and sometimes it remains (or to be more precise its parts that were not covered by the new image).

The cases in which it is gone are not the ones that the old image is smaller than the new one.

[doctordwarf]

zivgr
Actually I can't see the reason why old image should go away (if you don't use double buffering).

You painted old image. Then you updated some pixels with a new image. Why the remaining ones should go away? And what means "go away", how system would guess which color you consider being background one?
If you want to erase it, fill whole screen with some background color before painting new image there

Yep, I'm surprized that sometimes after the update, the last image is gone (which is what I want)

Could you post here main parts of your code?

[zivgr]

I'll try to isolate the relevant parts.
I know that in Canvas nothing is deleted but is painted again and that's why I'm surprised.
Concerning double buffering, I didn't implement it myself but maybe the phone does it automatically?

However, even if there is double buffering, As far as I understood double buffering is aimed to avoid flickering so is it relevant to our issue?

[doctordwarf]

zivgr
I know that in Canvas nothing is deleted but is painted again

Not really. I'd rather advise to think about Canvas as about an ordinary Image - just a pack of pixels to set color. You just paint over and over it. Not erasing old image, but putting a new one over.

Once again, how will system guess which color you consider being background one, to which value should it reset "automatically erased" pixels?

Concerning double buffering, I didn't implement it myself but maybe the phone does it automatically?
No, it doesn't

As far as I understood double buffering is aimed to avoid flickering so is it relevant to our issue?
It's times faster to draw something in memory and then just copy the whole picture. Of course if you need to alter just a small part of screen double buffering might not give large effect while eating memory.

so is it relevant to our issue?
If you painted everything in some screen-sized image and then copied it to screen, then everything old on the screen would be replaced.

[zivgr]

doube buffering -
Isn't the method isDoubleBuffered() answering this question???

[doctordwarf]

zivgr
Isn't the method isDoubleBuffered() answering this question???

It is, but not conserning your issue :)

public boolean isDoubleBuffered() - Checks if the Graphics is double buffered by the implementation.

This is a bit different double buffering. As I understand (I can be mistaken, hope you remember it :) ) if this method returns true, then you paint on a COMPLETE COPY of currently displayed screen. Hence, from the your program's point of view it is the same as there was no double buffering.

When I described it earlier, I had in mind that you might create/clear some image in memory for every frame and then copy it to screen.

[zivgr]

Thanks doctordwarf.
I think I found the problem.
The cases in which the Canvas is "deleted" are after another displayable is set to be current.
In the description of the function it is written that: "The contents of the Canvas are never saved if it is hidden and then is made visible again. "

so I assume this the answer.

[doctordwarf]

zivgr
The contents of the Canvas are never saved if it is hidden and then is made visible again

Yep :)
The actual screen is just a single pack of pixels used by different Froms, Canvases, etc.

[pekkert]

try calling serviceRepaints(); after your call to repaint. this makes the exec stop until the repaint has been done. if you dont call the
servicerepaints then you wont know when your repaint will be serviced.