Single buffer issues

Question

Single buffer issues

Closed this issue 7 months ago · 7 comments

60-hz commented 8 months ago

The creation of a window in single buffer mode needs the buffer to be cleared once before use, otherwise its size is wrong. (The old behavior didn't need to manually clear buffer before using it).
Force rendering on [gemhead] doesn't work, but abstraction [gem/gemhead] can draw. (should be related to #408)

MacOS with gemglfw3window, here is a simple patch to test:

single buffer issues.pd.zip

Answer 1 · 2024-02-01T09:15:53.000Z

hi, just wanted to report that 'buffer 1' message for gemwin is not working as the old versions.
I'm on win 11

untitled.mp4

Answer 2 · 2024-02-01T09:27:48.000Z

I think that you are not supposed to send "1" to gemwin in single buffering mode.
But you should manually send a "bang" to [gemhead] whenever you need to draw something...

Please test single buffer issues.pd.zip and report if it works for you. Weirdly enough I just tried with last deken version under MacOS (GEM: ver: 0.94.git v0.94-837-g56612c012) and I can draw using a bang to [gemhead] and also to [gem/gemhead] abstraction now...

Answer 3 · 2024-02-01T10:03:55.000Z

I downloaded again the last gem version from deken, and now it works like this, so it should be the right way, yes? but does this mean that in the past when I was switching from buffer 1 to buffer 2 and it was rendering everything like it's doing now, but with the metro triggering the gemhead, was a bug? becuase it was very usuful not to have to trigger all the gemheads in the buffer 1 mode, and to have the possibility to swtich between those modes on spot
https://github.com/umlaeute/Gem/assets/158454035/8dd322ce-82d5-4d3a-b91b-b9a3a55627a4

Answer 4 · 2024-02-01T10:32:37.000Z

I think that you are not supposed to send "1" to gemwin in single buffering mode.

But you should manually send a "bang" to [gemhead] whenever you need to draw something...

Please test single buffer issues.pd.zip and report if it works for you. Weirdly enough I just tried with last deken version under MacOS (GEM: ver: 0.94.git v0.94-837-g56612c012) and I can draw using a bang to [gemhead] and also to [gem/gemhead] abstraction now...

I note that triggering [gemhead] under MacOS single buffering actually draws, but returns a red error at every render:

gemlist: no method for 'context_active'
It does not trigger this error with [gem/geamhead].

I downloaded again the last gem version from deken, and now it works like this, so it should be the right way, yes? but does this mean that in the past when I was switching from buffer 1 to buffer 2 and it was rendering everything like it's doing now, but with the metro triggering the gemhead, was a bug? becuase it was very usuful not to have to trigger all the gemheads in the buffer 1 mode, and to have the possibility to swtich between those modes on spot
https://github.com/umlaeute/Gem/assets/158454035/8dd322ce-82d5-4d3a-b91b-b9a3a55627a4

Changing mode on spot is only possible since [gemglfw3window] is used as default, which allows many new message to be sent after windows creation. It's an interesting new feature yes, but then this message printed to the console is wrong and need to be removed:

[gemglfw3window]: changing buffer type will only effect newly created windows

Answer 5 · 2024-02-05T15:59:46.000Z

I've fixed the gemlist: no method for 'context_active' error (let's see what i broken by that).

as for the [gemglfw3window]: changing buffer type will only effect newly created windows warning:
Gem is actually right that you cannot really switch between single and double buffered on the fly.

however, when creating a single-buffered window and then (attempt to) switch to double-buffered mode, the automatic-rendering¹ (by sending a [1( to the [gemwin]) will clear the buffer, thus giving a similar result to double-buffered mode.

for now, I've turned the warning into a one-shot warning (that is: it's only emitted the first time you try to switch the buffer mode).

¹ i think that @60-hz is right that (iiuc) that auto-rendering was not supposed to work in single-buffered mode. it does now. not sure whether this should be turned into a promise :-)

PS: please don't use [gem/gemhead]: this only works because you are on a case-insensitive filesystem (e.g. here it would be [Gem/gemhead]. i think a better way to force the abstraction is to just use [./gemhead]

Answer 6 · 2024-02-05T16:01:23.000Z

I note that triggering [gemhead] under MacOS single buffering actually draws, but returns a red error at every render:

gemlist: no method for 'context_active'
It does not trigger this error with [gem/geamhead].

also note, that this error actually only appears (well: appeared) if you are mixing [gemhead] and [./gemhead], not if you are only using (as in: having in your patch) one or the other.

anyhow, it should be fixed.

Answer 7 · 2024-02-05T16:03:30.000Z

The creation of a window in single buffer mode needs the buffer to be cleared once before use, otherwise its size is wrong. (The old behavior didn't need to manually clear buffer before using it).

and this i couldn't reproduce (but i might have misunderstood the problem).
it's true that [gemglfw3window] - unlike eg [gemglxwindow] - would not report the dimension on window creation (only the framebuffer size). i've changed this to also report the window size.