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.
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.
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.
> 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.
> 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.
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:
> > 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.
Have you tried adding sleep(32) (or sleep(16), you need to experiment
with the values) to your on onTouchEvent handler? There is a known
issue with the GUI thread being bombarded with touch events when the
user touches the screen. The effect of these events can be to starve
your other threads of CPU time.
On Oct 5, 3:27 pm, 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:
> 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:
> > > 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.
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:
> 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:
> > > 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.
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.
> 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:
> > 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:
> > > > 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.
I'm trying to convert from using RENDERMODE_CONTINUOUSLY to
RENDERMODE_WHEN_DIRTY, to reduce overall system load -- the game view
is static a fair % of the time. It hasn't been working reliably,
probably for the reasons you describe in that post.
My input handling is essentially the same as what you describe as an
input pipeline, except for the mutex object -- it makes sense to use a
more specific mutex rather than the whole game loop. I will give that
a try -- I
However, I don't think that helps much to explain the flickering. But
I'll reserve judgement until I have a chance to try it :)
Jeremy
On Oct 5, 1:10 pm, Robert Green <rbgrn....@gmail.com> wrote:
> 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 theflicker.
> > 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:
> > 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:
> > > > On Oct 4, 7:36 am, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote:
> > > > > I did wonder about theOpenGLcommand 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 whereOpenGLis 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 theOpenGL
> > > > > 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 correctlyOpenGLinternally 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 toflicker-- 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 seeingflicker? 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.
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.
> > 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:
> > > 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:
> > > > > 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.
I just gotta ask. Is there any possibility that through an
optimization or any other way, there is a case where you're not
clearing and not drawing sometimes when a frame is drawn? I'm just
imagining a piece of code that says, "Did anything change? No? Then
just return." That would cause flicker.
On Oct 5, 3:17 pm, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote:
> I'm trying to convert from using RENDERMODE_CONTINUOUSLY to
> RENDERMODE_WHEN_DIRTY, to reduce overall system load -- the game view
> is static a fair % of the time. It hasn't been working reliably,
> probably for the reasons you describe in that post.
> My input handling is essentially the same as what you describe as an
> input pipeline, except for the mutex object -- it makes sense to use a
> more specific mutex rather than the whole game loop. I will give that
> a try -- I
> However, I don't think that helps much to explain the flickering. But
> I'll reserve judgement until I have a chance to try it :)
> Jeremy
> On Oct 5, 1:10 pm, Robert Green <rbgrn....@gmail.com> wrote:
> > 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 theflicker.
> > > 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:
> > > 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:
> > > > > On Oct 4, 7:36 am, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote:
> > > > > > I did wonder about theOpenGLcommand 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 whereOpenGLis 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 theOpenGL
> > > > > > 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 correctlyOpenGLinternally 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 toflicker-- 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 seeingflicker? 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.
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.
> 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.
> > > 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:
> > > > 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:
> > > > > > 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.
I do the "if anything updated" check in the game logic thread. If
something is changed, I post the requestRender() to the renderer. For
continuous-mode rendering, that shouldn't have any effect, as the
renderer will update regardless.
And as I explained in the original post, it is not the full scene that
flickers, only the last item(s) in the display list.
I appreciate all the random thoughts and suggestions, though!
Jeremy
On Oct 5, 2:25 pm, Robert Green <rbgrn....@gmail.com> wrote:
> I just gotta ask. Is there any possibility that through an
> optimization or any other way, there is a case where you're not
> clearing and not drawing sometimes when a frame is drawn? I'm just
> imagining a piece of code that says, "Did anything change? No? Then
> just return." That would causeflicker.
> On Oct 5, 3:17 pm, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote:
> > I'm trying to convert from using RENDERMODE_CONTINUOUSLY to
> > RENDERMODE_WHEN_DIRTY, to reduce overall system load -- the game view
> > is static a fair % of the time. It hasn't been working reliably,
> > probably for the reasons you describe in that post.
> > My input handling is essentially the same as what you describe as an
> > input pipeline, except for the mutex object -- it makes sense to use a
> > more specific mutex rather than the whole game loop. I will give that
> > a try -- I
> > However, I don't think that helps much to explain the flickering. But
> > I'll reserve judgement until I have a chance to try it :)
> > Jeremy
> > On Oct 5, 1:10 pm, Robert Green <rbgrn....@gmail.com> wrote:
> > > 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 theflicker.
> > > > 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:
> > > > 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:
> > > > > > On Oct 4, 7:36 am, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote:
> > > > > > > I did wonder about theOpenGLcommand 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 whereOpenGLis 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 theOpenGL
> > > > > > > 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 correctlyOpenGLinternally 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 toflicker-- 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 seeingflicker? 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.
I notice in your article the issue you describe seems to be
synchronization "fairness", i.e. Java doesn't make any fairness
guarantees about serving threads in the order they are waiting (though
I believe many Java implementations do). Have you tried the Semaphore
class? It allows you to specify whether it's fair or not in the
constructor.
On Oct 5, 12:10 pm, Robert Green <rbgrn....@gmail.com> wrote:
> 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:
> > 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:
> > > > 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.
> Have you tried adding sleep(32) (or sleep(16), you need to experiment
> with the values) to your on onTouchEvent handler? There is a known
> issue with the GUI thread being bombarded with touch events when the
> user touches the screen. The effect of these events can be to starve
> your other threads of CPU time.
> On Oct 5, 3:27 pm, 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 theflicker.
> > 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:
> > 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:
> > > > On Oct 4, 7:36 am, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote:
> > > > > I did wonder about theOpenGLcommand 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 whereOpenGLis 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 theOpenGL
> > > > > 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 correctlyOpenGLinternally 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 toflicker-- 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 seeingflicker? 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.
> 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:
> 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:
> > > 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.
Thanks for the explanation. I think I just took fairness for granted
and didn't realize that it was not guaranteed. I like the acquire()/
release() of semaphore. It's simple and sweet. I already do that
with my world to synchronize the logic and renderer but stuck to a
small synchronized block for input because it works fine in that area.
Jeremy,
Sorry, I didn't realize that it was only the last few objects in your
display list. Can you do a test if you haven't already? Can you cut
out all but 1 or so of the cows in the display list and see if it
still flickers? Basically mess with what you're drawing until you
start to see where problems occur?
On Oct 5, 5:05 pm, David Minor <davemi...@gmail.com> wrote:
> I notice in your article the issue you describe seems to be
> synchronization "fairness", i.e. Java doesn't make any fairness
> guarantees about serving threads in the order they are waiting (though
> I believe many Java implementations do). Have you tried the Semaphore
> class? It allows you to specify whether it's fair or not in the
> constructor.
> On Oct 5, 12:10 pm, Robert Green <rbgrn....@gmail.com> wrote:
> > 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:
> > > 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:
> > > > > 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.
