OpenGL composition artefacts

[anand b]

Hi,

We are seeing some artefacts while running the OpenGL application
"Translucent GLSurfaceView" on our board. Could you please help us to
understand what could be going wrong?

We see a flicker (where the background image is visible) for a short
time instead of 2 intersecting cubes. So, the final image is not
consistent.

Due to double bufferring in SurfaceFlinger, we expected to always see
a consistent image on the framebuffer irrespective of the
rendering/cpu speed.

Due to the flicker, it seems that the OpenGL composition in
SurfaceFlinger is somehow timed out and some triangles are not
processed. Is this the way SurfaceFlinger is implemented?

How can we ensure that SurfaceFlinger completes composition before a
frame is displayed?

We are using code from Android 1.0 release. Are there patches fixing
this issue and if so could you please point me to those?

Thanks,
Anand

[Mathias Agopian]

Could give more details? Which hardware is this?
Could be a bug in your display driver or GL driver.


Mathias

[anand b]

Hi Mathias,
We are using a ARM9 based board and the soft OpenGL implementation
available in Android.

We are using a WVGA display. For display driver, we are synching with
display interrupt so that should not be a problem. We will again check
the fb contents when they are posted.

We also see a similar problem with video. The video frame seems to be
made up of 2 triangles, but the diagonal line is visible for some
frames. This could be possible if the 2 triangles of the displayed
frame are from 2 different video frames.

So we are suspecting that the screen is not composited completely by
SurfaceFlinger. Can you give some hints?

Thanks,
Anand

[Mathias Agopian]

On Mon, Feb 2, 2009 at 8:06 PM, anand b <anan...@gmail.com> wrote:
>
> Hi Mathias,
> We are using a ARM9 based board and the soft OpenGL implementation
> available in Android.
>
> We are using a WVGA display. For display driver, we are synching with
> display interrupt so that should not be a problem. We will again check
> the fb contents when they are posted.
>
> We also see a similar problem with video. The video frame seems to be
> made up of 2 triangles, but the diagonal line is visible for some
> frames. This could be possible if the 2 triangles of the displayed
> frame are from 2 different video frames.
>
> So we are suspecting that the screen is not composited completely by
> SurfaceFlinger. Can you give some hints?

I don't know what's going on, but it surely looks like you're /dev/fb
synchronization doesn't work.

mathias

[Dima Zavin]

  We are using a ARM9 based board and the soft OpenGL implementation
available in Android.

 We are using a WVGA display. For display driver, we are synching with

Are you sure you have the horsepower to handle this with the ARM9? What frequency is the CPU at? What does your memory bandwidth look like? What is your refresh rate? 60Hz?

--Dima
 

[anand b]

Hi Dima,
Based on the double bufferred design of SurfaceFlinger, I expected it
to work (at a slow speed) with low mips as well.

When I hit a breakpoint just before flipping fb, I should not be
seeing any artefacts on the display if the frame composition has
completed. If there are less mips, this composition would take more
time. What is not clear is if the composition with soft OpenGL is
really complete when the framebuffer is posted !

regards,
anand

[Mathias Agopian]

On Wed, Feb 4, 2009 at 1:45 AM, anand b <anan...@gmail.com> wrote:
>
> Hi Dima,
> Based on the double bufferred design of SurfaceFlinger, I expected it
> to work (at a slow speed) with low mips as well.
>
> When I hit a breakpoint just before flipping fb, I should not be
> seeing any artefacts on the display if the frame composition has
> completed. If there are less mips, this composition would take more
> time. What is not clear is if the composition with soft OpenGL is
> really complete when the framebuffer is posted !

Yes it is. Unless the framebuffer is posted before it is complete
because of a bug in your display driver.

mathias