Hi,
I'm observing an unexpected behavior that may be a bug, but i'd like to be sure before I file it to the tracker, so please if anybody can show me this is the expected behavior and explain why, or confirm this is a bug, I would be grateful.
In the attached patch I have two gemheads; the first one is used just as a trigger (it is connected to a [t b]). The second one (their render order is relevant) is driving a pix_film.
What I do in the test patch is basically show the following situation:
- while the second gemhead is turned on, I send a frame number to its
pix_film, to place it at frame M, which is actually shown
- then I turn off the second gemhead
- the first gemhead is triggering a message with number N which is sent
through a spigot to pix_film's inlet, but the spigot is closed, so pix_film is not receiving the frame number and the last it received was M
- then I open that spigot so that pix_film will soon receive the number
N triggered by the first gemhead. Immediately, I also turn on the second gemhead which is driving the pix_film.
So I would expect the following to happen: at the next frame rendering, first the first gemhead will trigger the number N that will reach pix_film's inlet; then the second gemhead will output the gemlist (for the first time since it has been turned on), causing pix_film to output the new frame N which will show up on the rectangle as soon as it appears.
Instead, what I observe is the following: first the first gemhead triggers the number N that reaches pix_film's inlet; then the second gemhead outputs the gemlist, causing the rectangle to appear, but pix_film doesn't output a new image, so the rectangle appears with frame M as its texture. Only at the next frame, pix_film outputs the new image which is drawn on the rectangle.
So during one frame when the rectangle turns on, you see a flash of a frame you shouldn't see.
The attached patch shows (or I think it shows) that what happens is what I have described, that is, it shows that the order in which gemheads output their gemlists and the numbers are sent are the expected ones, and the unexpected thing is that pix_film outputs the new frame one frame too late.
To test the test patch you need a video called video.mov of at least 100 frames (I used M=100 and N=2). Just click on the bang at the top and watch the console.
Expected output:
..... =======: 1 G1_GEMLIST: bang GH2_FRAME: 2 GH2_GEMLIST: gem_state (pointer) (pointer) GH2_PIX_INFO: 1 0 G1_GEMLIST: bang GH2_FRAME: 2 GH2_GEMLIST: gem_state (pointer) (pointer) GH2_PIX_INFO: 0 0 G1_GEMLIST: bang GH2_FRAME: 2 GH2_GEMLIST: gem_state (pointer) (pointer) GH2_PIX_INFO: 0 0
Observed output:
..... =======: 1 G1_GEMLIST: bang GH2_FRAME: 2 GH2_GEMLIST: gem_state (pointer) (pointer) GH2_PIX_INFO: 0 0 G1_GEMLIST: bang GH2_FRAME: 2 GH2_GEMLIST: gem_state (pointer) (pointer) GH2_PIX_INFO: 1 0 G1_GEMLIST: bang GH2_FRAME: 2 GH2_GEMLIST: gem_state (pointer) (pointer) GH2_PIX_INFO: 0 0
Expected behavior when you bang: You see frame 100, then the screen goes black for a little while then suddenly you see frame 2
Observed behaviour: You see frame 100, then the screen goes black for a little while then you suddenly see frame 100 again for an instant (one frame) then you see frame 2
I cannot reproduce the same problem with only one gemhead. With only one gemhead, if I send pix_film a new number, and immediately turn on the gemhead, as soon as the rectangle appears it already shows the new frame, as I expect.
Thanks m.