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.
Have you try [route gem_state] after your [gemhead 1] ? Tell me if that work. Your patch seems complex, I don't test it. ++
Jack
Le mercredi 16 mars 2011 à 00:34 +0100, Matteo Sisti Sette a écrit :
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. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, should not work. ++
Jack
Le mercredi 16 mars 2011 à 01:12 +0100, Jack a écrit :
Have you try [route gem_state] after your [gemhead 1] ? Tell me if that work. Your patch seems complex, I don't test it. ++
Jack
Le mercredi 16 mars 2011 à 00:34 +0100, Matteo Sisti Sette a écrit :
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. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/16/2011 01:12 AM, Jack wrote:
Have you try [route gem_state] after your [gemhead 1] ? Tell me if that work.
It doesn't. I've also tried:
[route gem_state] | [list prepend gem_state] | [list trim]
which is, I guess, what you meant; but it works exactly as before (i.e. suffers from the same issue). I wouldn't expect anything to change, since gem_state should be the only message that comes out from gemhead
Your patch seems complex, I don't test it.
Obviously you don't have to.
I did take care to reduce the patch the bare minimum that I thought was needed to reproduce the issue (but I was wrong about that), and in such a way that only one click was needed to test it (I could have made it simpler but then you would need to follow accurately a complex set of instructions to reproduce it).
However I've found out I was wrong when I said:
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.
This is not true. The same issue DOES exist with only one gemhead. If pix_film receives the frame number just before its gemhead is turned on, it doesn't render the new frame untill one frame later.
If however the frame number is received more than one frame before the gemhead is turned on, then the new frame is rendered as soon as expected.
I'll send a simplified test patch later.
Thanks m.
The same issue DOES exist with only one gemhead. If pix_film receives the frame number just before its gemhead is turned on, it doesn't render the new frame untill one frame later.
Sorry, not quite exact yet.
It seems that:
- if I send the frame number to pix_film just before (in zero logical
time) I turn on its gemhead, then it works fine (renders the new frame immediately
- if I send the frame number to pix_film just before I send it the
gemlist (i.e., triggered by a [t a b] fed with the gemhead), then it doesn't generate the new image until the next frame.
This MAY be expected behavior. Can anyone confirm?
thanks m.
-
Jack -
Matteo Sisti Sette