Hello, I am experiencing a strange bug. See attachment. both patch works perfectly independently. But if I load both in the same time, then drawing a primitive in the buffer 1 patch works only 90% of the time.
can anyone reproduce this behaviours? (open the 2 patchs, create the 2 windows, play with primitive creation on the buffer1 patch : sometimes, when banging the primitive manually, it is not rendered.)
thanks for any suggestion.
cheers C
I noticed that I don't use multi context as explain in the documentation : the context for gemhead should be set with the "context" message. But using an argument is working (see test_buffer2), and using the context message did not change anything to my problem.
cheers c
Le 27/10/2023 à 14:46, cyrille henry a écrit :
Hello, I am experiencing a strange bug. See attachment. both patch works perfectly independently. But if I load both in the same time, then drawing a primitive in the buffer 1 patch works only 90% of the time.
can anyone reproduce this behaviours? (open the 2 patchs, create the 2 windows, play with primitive creation on the buffer1 patch : sometimes, when banging the primitive manually, it is not rendered.)
thanks for any suggestion.
cheers C
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
On 10/27/23 14:46, cyrille henry wrote:
Hello, I am experiencing a strange bug. See attachment. both patch works perfectly independently. But if I load both in the same time, then drawing a primitive in the buffer 1 patch works only 90% of the time.
can anyone reproduce this behaviours? (open the 2 patchs, create the 2 windows, play with primitive creation on the buffer1 patch : sometimes, when banging the primitive manually, it is not rendered.)
thanks for any suggestion.
sorry, i've missed this mail (not so much traffic on gem-dev these days :-)
i don't have an answer yet, but: - the context sharing behaviour is *highly* dependent on the windowing backend. with [gemglxwindow] i get the behaviour you describe, [gemglutwindow] doesn't work at all and [gemglfw3window] is somewhere inbetween. - clearing the single-buffered buffer (banging the [gemwin]) before writing to it always appears to work (but of course, this is not what you want)
gmasdr IOhannes
On 11/7/23 07:59, IOhannes m zmoelnig wrote:
i don't have an answer yet, but:
actually i think the problem is quite simple.
when banging a [gemhead] it doesn't ensure that the given openGL context is active. so if the single-buffer window isn't currently active, Gem is drawing "somewhere else". (i'm currently at a loss why it is drawing *at all*, that is: why does the single buffer window become active "sometimes" without being explicitly told)
i'm not sure about the actual solution though. should [gemhead] automatically ensure that the given context is active? (from a user perspective, the answer is probably a plain "yes"). or should there be an explicit message to [gemwin]? (similar to "bang" but without clearing the buffer)
mgfasdr IOhannes
hello Iohannes
Le 07/11/2023 à 08:25, IOhannes m zmoelnig a écrit :
On 11/7/23 07:59, IOhannes m zmoelnig wrote:
i don't have an answer yet, but:
actually i think the problem is quite simple.
look like it was, since I can't reproduce it since your last commit!
thanks for confirming the bug and fixing it! cheers C
when banging a [gemhead] it doesn't ensure that the given openGL context is active. so if the single-buffer window isn't currently active, Gem is drawing "somewhere else". (i'm currently at a loss why it is drawing *at all*, that is: why does the single buffer window become active "sometimes" without being explicitly told)
i'm not sure about the actual solution though. should [gemhead] automatically ensure that the given context is active? (from a user perspective, the answer is probably a plain "yes"). or should there be an explicit message to [gemwin]? (similar to "bang" but without clearing the buffer)
mgfasdr IOhannes
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
On 11/7/23 11:28, cyrille henry wrote:
hello Iohannes
Le 07/11/2023 à 08:25, IOhannes m zmoelnig a écrit :
On 11/7/23 07:59, IOhannes m zmoelnig wrote:
i don't have an answer yet, but:
actually i think the problem is quite simple.
look like it was, since I can't reproduce it since your last commit!
thanks for confirming the bug and fixing it!
alas! my fix opened another can of worms. e.g. 10.GPU_physical_model.pd is now practically brokwn...
https://github.com/umlaeute/Gem/issues/391
lets see if I can come up with something else...
fdasmr IOhannes
-
cyrille henry -
IOhannes m zmoelnig