flickering

[maho]

See example:

hg clone -r 111241e https://bitbucket.org/maho/tmpkh2/
cd tmpkh2
python khamster.py

What I see, is character which initially flickers a bit. Sometimes unnoticeable. But every few second, entity is removed and created again. And then it flickers more. After several second, flickering is very, very noticeable.

[maho]

forgot to mention that it regards new_model_format branch from kivent

[maho]

more prominent (and more minimal, removed physics and boundary systems and lot of images from atlas) example is in repo,

hg clone -r example2 https://bitbucket.org/maho/tmpkh2/
cd tmpkh2
python khamster.py

When I run it, I see hamster going to and thru. In theory it should move smoothly (it logs position to debug and positions chnges are smooth), but it's movement is ragged. From time to time it looks like going step backward. Effects is more and more prominent when you wait.

For me, it looks like frame with texture X is not written in current position, but in position when it was some time ago. Not always, but sometimes. And not last time, but eg. few seconds ago.

I think that it's matter with batch reusing, because when I comment out such code:

     #TODO fix me, seg faults
    if batch.check_empty():
        self.remove_batch(batch_id)

in batching pyx, then effect looks like gone (but probably there is huge memory leak)

[Kovak]

Hey @mahomahomaho

Saw you tried to get a hold of me on IRC. Wanted to say I haven't had a chance to look into this issue yet, but I have not forgotten you either. I will get to it.

[Kovak]

Why do you create a new entity every 4 frames? This contributes to your jerky motion (if you increase the speed of your gamesystem update you will notice you usually actually have 2 birds on screen because the time between frames is so short the eye cannot tell), but you also do not incorporate dt into your position calculation, and only calculate a new position every .1 seconds. If you want smooth motion you need to both use a faster update time and incorporate time into your position calculation. Notice how position is calculated by multiplying a velocity by dt and adding to current position here: https://github.com/kivy/kivent/blob/master/examples/3_creating_a_gamesystem/main.py#L24

Your update function moves the position of the sprite by 20 pixels each update, this is nowhere near smooth motion.

[maho]

re our irc chat today:

• modified source:

  hg clone -r example3 https://bitbucket.org/maho/tmpkh2/
  cd tmpkh2
  python khamster.py

Note. that there is no more removing and adding entity.

• movie: http://files.pagema.net/case.ogv - flickering starts from 14 second.

[maho]

I have written wrong hg url in previous comment (edited already). Proper is hg clone -r example3 ........

[maho]

And few consecutive frames from move above with red marks about error

[maho]

And the same, more visible ~2seconds later.

[maho]

after exhaustive digging and experiments, I think that it happens when IndexBatch.draw_frame() increments current_frame too far, to frame which is not yet prepared.

If I understand it correctly, frame is prepared in renderrer update, while CMesh.apply (which calls IndexBatch.draw_frame) is called from somewhere(from where?), and sometimes is called twice. Then frame counter advances too much and we have flicker.

So my idea is to move advancing counter from batch.draw_frame to RotateRenderer.update

I will prepare pull request tomorrow (sad thing is, that it's solution for -r example3, but not for example2)

[Kovak]

CMesh.apply calls the draw_fame as a result of Renderer.update calling flag_update on the mesh instruction. Renderers are updated exactly once per frame, or should be. Can you share your evidence that it is being called twice?

[maho]

Yes. I have added loggers into kivent as in diff, ran

  hg clone -r example3 https://bitbucket.org/maho/tmpkh2/ 
  cd tmpkh2
  python khamster.py

and I see in logs:

 [...]
 [DEBUG  ] [RotateRenderer.update] prepare frame data (current_frame=15)
 [DEBUG  ] [Batch.draw_frame] current_frame = 15
 [DEBUG  ] [RotateRenderer.update] prepare frame data (current_frame=16)
 [DEBUG  ] [game        ] update: new texture is hamster-phase2-1
 [DEBUG  ] [Batch.draw_frame] current_frame = 16

so far everything goes ok,

 [DEBUG  ] [RotateRenderer.update] prepare frame data (current_frame=17)
 [DEBUG  ] [Batch.draw_frame] current_frame = 17
 [DEBUG  ] [Batch.draw_frame] current_frame = 18

flickers here^^^^

 [DEBUG  ] [RotateRenderer.update] prepare frame data (current_frame=19)
 [DEBUG  ] [game        ] update: new texture is hamster-phase2-2
 [DEBUG  ] [Batch.draw_frame] current_frame = 19

and then ok again.

[Kovak]

where are you logging the Batch.draw_frame and the RotateRenderer.update? I cannot duplicate the logs you have printed out here. Given that current_frame is incremented only after calling glDrawElements, the 'proper place' for advancing current_frame is where it is now. Your PR is not an appropriate fix.

[Kovak]

@mahomahomaho thanks very much for sticking with this issue! Great diagnoses, and you did find the right solution. I have pushed a fix that is very similar to your PR, but instead of locating the current_frame increment in Renderer, it is in CMesh. Give the latest changes a pull and let me know if it fixes things for you over here.

[maho]

well, strange thing - I downloaded example3 again (to remind you:

hg clone -r example3 https://bitbucket.org/maho/tmpkh2/ 
cd tmpkh2
python khamster.py

), ran it with recent 2.2-dev branch and it's flickering like a hell.

I did bisect and I see that it starts in rev 4f277d7 - revision earlier, in c7212e2, everything is ok.

I have tried to undo changes between c7212e2 and 4f277d7 in 2.2-dev, but didn't help.

[maho]

I hoped that rewriting to animationsystem will help, but it has exactly the same.

Steps to reproduce:

hg clone -r ex3animsystem https://bitbucket.org/maho/tmpkh2/ 
cd tmpkh2
python khamster.py

animation is created in such way: https://bitbucket.org/maho/tmpkh2/src/461425a1e176773941fb210c6d5fb0c303b13643/game.py?fileviewer=file-view-default#game.py-43

[maho]

Okay, when I switched order of AnimationSystem and Renderer in .kv, it doesn't flicker. Which reminds me that order of systems is important re flickering. I remember that we were discussing it before, but I cannot google it out.

So there are two doubts:

1. if it's error or not, if I should be able to define wrong order of systems which produces flickering, or I should get either error or it should re-order itself?
2. if I should take care about order, is order of definitions in .kv good way to ensure proper order, or not?

Order is important, because when unbatch in animation, then it take place immediately on the screen. But batch and generally draw - on next iteration of update of renderrer. So when renderrer is before animation, then it's draw, unbatch, pause between frames (flicker), draw.

when animation is before renderrer, then it's unbatch, batch, draw, pause.

I'm not sure if second case is "no flickering" or "flickering so fast that almost nobody can see it" :).

[maho]

I close this issue, because discussion lead us to somewhere near nowhere :)