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.