Hi, i would like to understand why i've this sort of message on the DDMS :

02-24 02:35:06.556: WARN/SurfaceComposerClient(360): lock_layer timed out (is the CPU pegged?) layer=0, lcblk=0x41018020, state=00000002 (was 00000043)
02-24 02:35:06.566: WARN/SurfaceComposerClient(360): lock_layer() timed out but didn't appear to need to be locked and we recovered (layer=0, lcblk=0x41018020, state=00000002)
02-24 02:35:07.396: WARN/SurfaceFlinger(49): executeScheduledBroadcasts() skipped, contention on the client. We'll try again later...
02-24 02:35:08.686: WARN/SurfaceFlinger(49): executeScheduledBroadcasts() skipped, contention on the client. We'll try again later...
02-24 02:35:23.227: WARN/SurfaceFlinger(49): executeScheduledBroadcasts() skipped, contention on the client. We'll try again later...
02-24 02:35:25.197: WARN/SurfaceFlinger(49): executeScheduledBroadcasts() skipped, contention on the client. We'll try again later...
02-24 02:35:46.256: WARN/SurfaceFlinger(49): executeScheduledBroadcasts() skipped, contention on the client. We'll try again later...
02-24 02:35:51.107: WARN/SurfaceFlinger(49): executeScheduledBroadcasts() skipped, contention on the client. We'll try again later...
02-24 02:36:00.286: INFO/dalvikvm(49): threadid=39: bogus mon 1+0>0; adjusting

thx so much ^^

My EXTREMELY wild guess: You are locking the canvas of a surface view en while you have the lock, you keep looping, but you need to release the lock every frame...

Hi

I get this error when I draw an opnegl view above the camera view. I am doing augmented reality stuff so I need to use opengl to draw markers and stuff above the camera view. Currently Im trying t draw the cube from the SDK above the camera but get the executeScheduledBroadcasts() skipped, contention... problem. I guess it has something to do with th 2 different view trying to use the same resources or something.


Does anybody have some hint for me on this?

Cheers
Magnus

Yeah, only one thread can access a canvas/surface at a time (I guess, as it's part of the UI).

Yepp thats seems to be the problem but how do I fix it. If I did it in Java Desktop I would use the AWT thread but how can I remedy that I access the surface from 2 threads. I mean any tips on how to implement this?


Cheers
Magnus

Don't really know, it's highly dependent on your code...

Ok do you know if one can aquire a unique lock to the surface? My code is quit simple I have a classic camera view that displays the camera preview and I have a OpenGL view that has a GLThread that just takes tasks from a queue and draws them. I guess thats where it collides. Since the camera view is handling the drawing in the Camera class I guess it will be hard to force everything to draw on the same thread if of cause there not a AWT similar thread i Android that I can post my drawings on?

Magnus

Check the lunar lander demo, it locks the canvas.

It seems to be a bad idea to have the opengl stuff run in its own thread for this. In the API demo there is only one view running for the activity and that is driven by the thread and since no one else is competing for the canvas there will be no problem.

Maybe I should let the camera drive the application so that in the onPreviewFrame I will draw the opengl view. Most likely the camera first calls this method so I can alter the byte[] array and then draws. Hopefully it hasn't required the lock for the canvas before calling the callback method.

By the way can I have 2 surfaces for an activity and then let one of them overlay the other? Can I even get 2 surfaces for 1 activity or is it a 1 to 1 relationship?

Sorry for the stupid questions but as usual Im in a hurry and need to get it up and running so ask and I will receive

Cheers

Magnus

You could make the OpenGL Render thread wait, when it still has the lock and run the AR render thread only when the OpenGL Thread is waiting.
Or call the AR rendering thread from the OpenGL rendering routine and give the surface as argument or something like that.

Im gonna try to explain in more detail what Im tryign to do and hope fully someone has a answer that can help me.

We are building an Augmented Reality engine for the Android platform. This will be a complete engine in the end we hope but to start with we gonna do what the Enkin guys did among others.

In the first view we will have the camera running showing whats in-font of it. The we will draw stuff onto a layer above the camera view that shows information about specific building,landmarks etc. We are planning on using opengl and positioning the virtual camera where the real camera on the phone is and then use the GPS, accelerometer and compass to figure out where the camera is pointing. That way we can use the open gl engine to get perspective etc. Maybe we should skip the opengl stuff and just draw text directly to the surface using 2D and just have the text size or transparency show position.

So our first challenge is to get the camera view up and running and then let the opengl view draw stuff on top of it. Since the camera view is drawing a number of key frames per second we do not want the opengl stuff to be limited to the frame rate. We want the opengl stuff to draw as fast as possible and on a layer by it self. I guess we need to have some sort of composting engine that draws to different framebuffers in the lower level opengl layers.

So questions are then

1. Is there a possibility to use multiple surfaces in an activity that creates layers above each other. That way we could draw the opengl stuff to one buffer and the camera view to another buffer. This will give the illusion of the augmented reality stuff being really fast and responsive and no controlled by the frame rate of the cameras.


2. If there is no way of composing the way I described above how do I do this the best way? In the API demos they have created a GL thread that continues to draw as fast as possible to the surface. Since the camera is also drawing to the surface we will get conflicts. For me it sounds a bit mad if we have to synchronize the different threads using a common synch object but is that the case? If so how do I implement that we the existing camera.setPreviewDisplay method since I have no control over how the camera is drawinf to the surface

3. Im a bit curious on the onDras method? How often does it get called? Is it based on the possible framerate of the hardware or is it slower. Maybe it just gets called when somethign changes but since I tried that out to overlay above the camera view I guess it happens each time the camera view redraws. In tha case does the camera previwew draw as fast as it can or is it set to a rate?



If someone is doing augmented reality stuff that wants to help out give me a shout

Cheers
M