I just read your post. Looks like I hit the same problem about 6 months ago. I even managed to create a mostly-reproducible test case so that I could file an issue: http://code.google.com/p/android/issues/detail?id=1956
(I can only think that it's some sort of fairness issue with monitors) <http://code.google.com/p/android/issues/detail?id=1956>My solution was in the same spirit, but actually uses a simple synchronization-free circular event buffer that instead uses volatiles to guarantee correct execution. Tom. 2009/10/5 Robert Green <[email protected]> > > I just thought of something. You said your logic thread sleeps? Are > you using RENDERMODE_CONTINUOUSLY? > > Here's a shot in the dark. I feel like your renderer isn't clearing > the color buffer and isn't drawing anything, and that maybe happens > when there's a certain state of the logic thread somehow. Drawing a > frame without clearing the color buffer and without drawing anything > will make for some wild flickering but the image will still be there, > just flickery. I noticed that when I was messing with skyboxes and > had my clear command off. > > By the way, I don't recommend handling input the way you are. I > switched all my games to use input pipelines and they have saved me a > load of trouble. I get super fast response and don't have to > synchronize with a common thread mutex, which I have always had issues > with it not giving up the lock to another thread. I wrote an article > just now that you can take a look at if you're interested in switching > - http://www.rbgrn.net/content/342-using-input-pipelines-your-android-game > > > On Oct 5, 9:27 am, Jeremy Slade <[email protected]> wrote: > > I'm definitely not getting anywhere close to that limit > > (GL_MAX_ELEMENTS_VERTICES). > > > > I'm pretty close to a root cause for at least a large percentage of > > the flickering events... It has something to do with my thread > > synchronization, but it's not obvious to me how it causes the flicker. > > > > I have three threads: > > * main / UI thread > > * logic thread > > * rendering thread (created by GLSurfaceView) > > > > The majority of the flickering happens when I do something to generate > > UI events (touch the screen, move the trackball, etc). I end up > > passing a message to the logic thread, which may be sleeping: > > > > public void queueGameEvent(GameEvent ev) { > > synchronized(mGameLoop) { > > if ( first_event != null ) first_event.next_event = ev; > > else first_event = ev; > > ev.next_event = null; > > //mGameLoop.notifyAll(); // wake sleeping threads > > } > > } > > > > When I have the notfyAll() call enabled, it flickers badly. Without > > it, I rarely see flickers (still some, though). That method is called > > from the UI thread, and should result in waking up the logic thread. > > Any ideas on how / why that affects the rendering? > > > > Thanks, > > Jeremy > > > > On Oct 4, 6:05 pm, Robert Green <[email protected]> wrote: > > > > > The G1 reports 65536 for that parameter. > > > > > On Oct 4, 7:06 am, RichardC <[email protected]> wrote: > > > > > > You could try > > > > > > glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, &value); > > > > > > Have not tried this myself but found it in > > > > > >http://gpwiki.org/forums/viewtopic.php?t=8839 > > > > > > On Oct 4, 7:36 am, Jeremy Slade <[email protected]> wrote: > > > > > > > I did wonder about the OpenGL command buffer limit -- any way to > > > > > verify for sure that I am hitting it? > > > > > > > I would be surprised if that's the case, though -- it's not a real > > > > > complex scene, maybe 3000-4000 textured triangles. But I'll admit > to > > > > > being almost a complete novice where OpenGL is concerned... > > > > > > > The various meshes are all done with glDrawElements(). 95% of this > is > > > > > in the cow mesh -- same mesh drawn w/ different transforms, and > > > > > different textures bound each time. The mesh itself uses ~54k of > > > > > memory for vertices + normals + tex coords. How big is the OpenGL > > > > > buffer? seems like it's got to be significantly larger than that. > > > > > > > On Oct 3, 1:29 pm, RichardC <[email protected]> > wrote: > > > > > > > > If I remember correctly OpenGL internally has a limit to the > number of > > > > > > items it can hold in it's display list. When the list gets full > it's > > > > > > starts drawing rather than dropping your items. To achieve this > it > > > > > > flips the buffers and draws the remaining items on the live > screen. > > > > > > > > If I am remembering correcly this could explain what you are > seeing. > > > > > > > > -- > > > > > > Ruchard > > > > > > > > On Oct 3, 8:08 pm, Jeremy Slade <[email protected]> > wrote: > > > > > > > > > I'm trying to clean up some rendering issues for a 3D game -- > > > > > > > CowPotato (http://www.cyrket.com/package/ > > > > > > > com.froogloid.android.cowpotato). I could use some help on one > issue. > > > > > > > > > Basically I'm seeing some flickering, like the next frame is > getting > > > > > > > flushed before everything is drawn. It is definitely the last > few > > > > > > > items in my display list that seem to flicker -- if I reorder > the > > > > > > > list, it's always the last part of the list that flickers. > > > > > > > > > I understand that the GLSurfaceView automatically provides > double- > > > > > > > buffering -- it certainly appears to be the case looking at the > > > > > > > source. So any suggestions as to why I might be seeing > flicker? I > > > > > > > put counters into the drawing methods to make sure that all the > > > > > > > objects are called each frame, they just don't show up on > screen all > > > > > > > the time. > > > > > > > > > Any insight would be appreciated. > > > > > > > > > Jeremy > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
