Warning, pure speculation follows: Touching the screen generates events very rapidly, and using the trackball probably does too. Anecdotally, I encountered the bug with increasing frequency as the work done within the synchronized block lengthened (I think - it was a while ago and I can't recall all the details).
So I'm willing to take a guess that the probability of triggering the bug rises with both contention and frequency, meaning that even a very 'small' synchronized block could trigger it, even though it's extremely unlikely that it ever could. That's why I went for a sync-block-free implementation, just to make sure. Tom. 2009/10/5 Jeremy Slade <jeremy.g.sl...@gmail.com> > > The issue you filed focuses on touch event handling, but I see > flickering just as much with trackball events. If it is a fundamental > thread scheduling issue, I guess it wouldn't matter the type or even > frequency of events being generated. > > On Oct 5, 2:01 pm, Tom Gibara <m...@tomgibara.com> wrote: > > 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 <rbgrn....@gmail.com> > > > > > > > > > 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 <jeremy.g.sl...@gmail.com> 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 <rbgrn....@gmail.com> wrote: > > > > > > > The G1 reports 65536 for that parameter. > > > > > > > On Oct 4, 7:06 am, RichardC <richard.crit...@googlemail.com> > 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 <jeremy.g.sl...@gmail.com> > 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 <richard.crit...@googlemail.com> > > > 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 <jeremy.g.sl...@gmail.com> > > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
