Android - flickering while switching Displayable

[GoogleCodeExporter]

When midlet switching Displayable (fullscreen Canvas) I see some flickering.
With r2211 (as recommended in Android J2me converting manual) it is not so 
annoying, but in later revisions next Canvas sometime not cover all display 
area.

Tested with Android SDK emulator and r2211, r2377, r2390. 

Original issue reported on code.google.com by vitalyster on 15 Jun 2010 at 7:17

[GoogleCodeExporter]

r2392 much better, with one issue:

Canvas.getHeight() and Graphics.getClipHeight() return different values, Canvas 
returns incorrect value.

Original comment by vitalyster on 17 Jun 2010 at 7:58

[GoogleCodeExporter]

Does "much better" means that there is no flickering now (with r2392)?

Original comment by bar...@gmail.com on 18 Jun 2010 at 6:17

[GoogleCodeExporter]

There is no flickering, but if Displayable relies on Canvas height and width - 
it may paints incorrectly, under display area, or so. Switching more times may 
obtain right size, may not.

Original comment by vitalyster on 18 Jun 2010 at 11:06

[GoogleCodeExporter]

I'm not entirely sure what "switching Displayable" means. Is that a flipping a 
device from portait to the landscape position or switching between two 
different Displayable objects?

Original comment by bar...@gmail.com on 18 Jun 2010 at 12:36

[GoogleCodeExporter]

it is: 
http://java.sun.com/javame/reference/apis/jsr037/javax/microedition/lcdui/Displa
y.html#setCurrent(javax.microedition.lcdui.Displayable)

Original comment by vitalyster on 18 Jun 2010 at 12:57

[GoogleCodeExporter]

I discover that regression was in r2304, older revisions returns size correctly

Original comment by vitalyster on 28 Jun 2010 at 3:16

[GoogleCodeExporter]

r2423 improve size calculating, with attached patch it improve calculating more.

Original comment by vitalyster on 4 Nov 2010 at 6:01

Attachments:

• canvas.patch

[GoogleCodeExporter]

One question, you added to CanvasView:

        @Override
        public void onSizeChanged(int w, int h, int oldw, int oldh) {
            initGraphics(w, h);
        }

Is it necessary? I mean, there is already surfaceChanged callback mathod set in 
CanvasView which calls initGraphics with new size of the view.

Original comment by bar...@gmail.com on 4 Nov 2010 at 8:35

[GoogleCodeExporter]

Yes, it not needed, I got debug log and see, that surfaceChanged properly 
called on device rotation and tell right sizes to application. But graphics 
still may paints incorrectly after several size changes, I have no idea why.

Original comment by vitalyster on 9 Nov 2010 at 2:59

[GoogleCodeExporter]

r2446 is great - after device rotation graphics area first draws incorrectly 
but in second or shorter time period it repaints correctly.

Original comment by vitalyster on 25 Nov 2010 at 8:54

[GoogleCodeExporter]

I admit I haven't checked the canvas code thoroughly, so, I wonder how is 
sizeChanged event propagated user's Canvas? 

In my midlet I'm using GameCanvas, and I had to modify AndroidCanvasUI in order 
to have sizeChanged callback invoked (my diff against r2446 attached). But it 
was a long time, so maybe I should review it...

Original comment by kr...@seznam.cz on 26 Nov 2010 at 2:12

Attachments:

• acui.diff

[GoogleCodeExporter]

r2447 calls the Canvas.sizeChanged. I modified the acui.diff in some places, 
but the functionality should be the same.

Original comment by bar...@gmail.com on 30 Nov 2010 at 3:34

[GoogleCodeExporter]

Now greatly works with sizeChanged, but an older bug come again: after 
Display.setCurrent(...) - new Displayable(Canvas) not paints (showing black 
screen) until we explicitly call repaint().

Original comment by vitalyster on 7 Dec 2010 at 9:21

[GoogleCodeExporter]

I've made some simpifications to AndroidCanvasUI: CanvasView extends base View 
class instead of SurfaceView, and haven't any listed problems with flickering 
and size changes. I think that is enough for simple (all j2me?) applications.

Original comment by vitalyster on 8 Dec 2010 at 6:03

Attachments:

• SimpleCanvasUI.patch

[GoogleCodeExporter]

I'm afraid I cannot accept the patch since you removed the 
setAndroidRepaintListener method from AndroidCanvasUI class. That functionality 
is used by other projects. Also graphics object accessible from getGraphics is 
created every time when onDraw method is called.

Original comment by bar...@gmail.com on 8 Dec 2010 at 8:11

[GoogleCodeExporter]

second try: restored setAndroidRepaintListener and initGraphics methods

Original comment by vitalyster on 8 Dec 2010 at 11:38

Attachments:

• simpleacui2.patch

[GoogleCodeExporter]

I can see one problem with the latest patch, it removes support for scaling, 
previously it was handled in onDraw by:
androidCanvas.drawBitmap(bitmap, scale, null);

Original comment by bar...@gmail.com on 8 Dec 2010 at 2:05

[GoogleCodeExporter]

If we can modify initGraphics parameters signature, then this patch should 
handle scaling properly

Original comment by vitalyster on 8 Dec 2010 at 3:33

Attachments:

• simpleacui3.patch

[GoogleCodeExporter]

simpleacui3.patch has been applied, let's test our applications now

Original comment by bar...@gmail.com on 20 Dec 2010 at 1:17

[GoogleCodeExporter]

I had to revert the simpleacui3.patch since it makes flickering (repainting a 
canvas in a loop, causes the entire canvas to flicker with a white background).

while(true) {
   repaint();
   serviceRepaints();
}

Original comment by bar...@gmail.com on 5 Jan 2011 at 1:18

[GoogleCodeExporter]

Original comment by bar...@gmail.com on 17 Jan 2011 at 6:57

• Changed state: Fixed
• Added labels: Milestone-3.0