Hey all
I'm working on patch that displays a lot (30 lines, 76 chars per line) of text in a Gem window using [text2d]. I observed that CPU usage increases proportional to the string length sent to [text2d]. It appears to me that [text2d] renders the given string for each frame. The fact that frame rate and CPU usage are proportional, too, confirms this assumption.
Now, I'd like to make my patch less CPU hungry and thought about switching to single buffer mode, since it would be sufficient to update the gemwin only when the text changes, which is far less often than running gemwin at any fixed frame rate. Now my real problem begins. Whenever the text/string changes, I clear the buffer, send the string to [text2d] and bang the [gemhead], so that the display is refreshed (in this exact order). However, when I perform this steps in zero logical time, I get a blank screen. Only when I delay the bang to [gemhead] by a few milliseconds, I get text in the gemwin.
I just noticed now that this is not related to [text2d] at all, but seems an issue between [gemwin] and [gemhead]. [gemhead] can't render a certain amount of time after [gemwin] has been cleared. Is there a way to know when [gemhead] is ready to render (or when [gemwin] has finished clearing)?
Roman
Hello Roman,
First, you should try with [text3d] instead of [text2d], on my configuration, [text3d] is faster.
About single buffer mode. Did you send à [0( to the [gemhead] at startup ? Look at the patch attached, everything is ok in 0 logical time. On my side, it is strange that i need to send 2 [bang(s to [gemwin] to clear the buffer. ++
Jack
Le 15/09/2016 à 17:58, Roman Haefeli a écrit :
Hey all
I'm working on patch that displays a lot (30 lines, 76 chars per line) of text in a Gem window using [text2d]. I observed that CPU usage increases proportional to the string length sent to [text2d]. It appears to me that [text2d] renders the given string for each frame. The fact that frame rate and CPU usage are proportional, too, confirms this assumption.
Now, I'd like to make my patch less CPU hungry and thought about switching to single buffer mode, since it would be sufficient to update the gemwin only when the text changes, which is far less often than running gemwin at any fixed frame rate. Now my real problem begins. Whenever the text/string changes, I clear the buffer, send the string to [text2d] and bang the [gemhead], so that the display is refreshed (in this exact order). However, when I perform this steps in zero logical time, I get a blank screen. Only when I delay the bang to [gemhead] by a few milliseconds, I get text in the gemwin.
I just noticed now that this is not related to [text2d] at all, but seems an issue between [gemwin] and [gemhead]. [gemhead] can't render a certain amount of time after [gemwin] has been cleared. Is there a way to know when [gemhead] is ready to render (or when [gemwin] has finished clearing)?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Don, 2016-09-15 at 18:45 +0200, Jack wrote:
Hello Roman,
First, you should try with [text3d] instead of [text2d], on my configuration, [text3d] is faster.
You right about [text3d] being faster. It's even a lot faster, but also dead ugly. I prefer the rendering result of [text2d]. I don't understand what the difference between those is, actually. Does [text3d] render the text onto a texture on a plane? Does [text2d] render the font as 3d vector?
About single buffer mode. Did you send à [0( to the [gemhead] at startup ?
Yes.
Look at the patch attached, everything is ok in 0 logical time. On my side, it is strange that i need to send 2 [bang(s to [gemwin] to clear the buffer.
Your patch works for me, too, as you probably intended it to work. What I want is actually the buffer to be cleared before each step, so that the result looks similar to double buffer mode, where only one word appears at the time.
See attached patch. I get only a blank screen and occasionally a single word appearing. It works somewhat more reliable when I insert a [delay 50] between [t b b b] and [gemhead].
Now that you triggered me to have a more deeper look into [text3d], I found I simply can put [text3d] further away (z=-4) and make the font bigger at the same time and then quality becomes comparable to [text2d]. So, I guess my problem is solved. Thanks for the hint!
I still wonder how one can reliably clear buffer and draw something in zero logical time or at least in some deterministic way when using single buffer mode.
Roman
Le 15/09/2016 à 17:58, Roman Haefeli a écrit :
Hey all
I'm working on patch that displays a lot (30 lines, 76 chars per line) of text in a Gem window using [text2d]. I observed that CPU usage increases proportional to the string length sent to [text2d]. It appears to me that [text2d] renders the given string for each frame. The fact that frame rate and CPU usage are proportional, too, confirms this assumption.
Now, I'd like to make my patch less CPU hungry and thought about switching to single buffer mode, since it would be sufficient to update the gemwin only when the text changes, which is far less often than running gemwin at any fixed frame rate. Now my real problem begins. Whenever the text/string changes, I clear the buffer, send the string to [text2d] and bang the [gemhead], so that the display is refreshed (in this exact order). However, when I perform this steps in zero logical time, I get a blank screen. Only when I delay the bang to [gemhead] by a few milliseconds, I get text in the gemwin.
I just noticed now that this is not related to [text2d] at all, but seems an issue between [gemwin] and [gemhead]. [gemhead] can't render a certain amount of time after [gemwin] has been cleared. Is there a way to know when [gemhead] is ready to render (or when [gemwin] has finished clearing)?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
Le 15/09/2016 à 20:58, Roman Haefeli a écrit :
On Don, 2016-09-15 at 18:45 +0200, Jack wrote:
Hello Roman,
First, you should try with [text3d] instead of [text2d], on my configuration, [text3d] is faster.
You right about [text3d] being faster. It's even a lot faster, but also dead ugly. I prefer the rendering result of [text2d]. I don't understand what the difference between those is, actually. Does [text3d] render the text onto a texture on a plane? Does [text2d] render the font as 3d vector?
With the default settings, [text3d] (if i remember right) create a texture for anti aliasing. So you can change anti aliasing with the message "alias". If you send [alias 0(, you work with vertices (if i am right here again), then you can ask to your driver to use anti-aliasing, or not.
About single buffer mode. Did you send à [0( to the [gemhead] at startup ?
Yes.
Look at the patch attached, everything is ok in 0 logical time. On my side, it is strange that i need to send 2 [bang(s to [gemwin] to clear the buffer.
Your patch works for me, too, as you probably intended it to work. What I want is actually the buffer to be cleared before each step, so that the result looks similar to double buffer mode, where only one word appears at the time.
See attached patch. I get only a blank screen and occasionally a single word appearing. It works somewhat more reliable when I insert a [delay 50] between [t b b b] and [gemhead].
OK. see patch attached. It seems to work in 0 logical time. The 'bang' to clear the buffer is sent just after the 'bang' sent to gemhead (it is weird, and i can't remember if the behavior was like this before ?). So yes, it could be a bug because now to clear the buffer, you need to :
- send a bang to gemwin
- send a bang to gemhead
Now that you triggered me to have a more deeper look into [text3d], I found I simply can put [text3d] further away (z=-4) and make the font bigger at the same time and then quality becomes comparable to [text2d]. So, I guess my problem is solved. Thanks for the hint!
Look at the message 'alias' to solve this issue. ++
Jack
I still wonder how one can reliably clear buffer and draw something in zero logical time or at least in some deterministic way when using single buffer mode.
Roman
Le 15/09/2016 à 17:58, Roman Haefeli a écrit :
Hey all
I'm working on patch that displays a lot (30 lines, 76 chars per line) of text in a Gem window using [text2d]. I observed that CPU usage increases proportional to the string length sent to [text2d]. It appears to me that [text2d] renders the given string for each frame. The fact that frame rate and CPU usage are proportional, too, confirms this assumption.
Now, I'd like to make my patch less CPU hungry and thought about switching to single buffer mode, since it would be sufficient to update the gemwin only when the text changes, which is far less often than running gemwin at any fixed frame rate. Now my real problem begins. Whenever the text/string changes, I clear the buffer, send the string to [text2d] and bang the [gemhead], so that the display is refreshed (in this exact order). However, when I perform this steps in zero logical time, I get a blank screen. Only when I delay the bang to [gemhead] by a few milliseconds, I get text in the gemwin.
I just noticed now that this is not related to [text2d] at all, but seems an issue between [gemwin] and [gemhead]. [gemhead] can't render a certain amount of time after [gemwin] has been cleared. Is there a way to know when [gemhead] is ready to render (or when [gemwin] has finished clearing)?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, 2016-09-15 at 23:52 +0200, Jack wrote:
Le 15/09/2016 à 20:58, Roman Haefeli a écrit :
On Don, 2016-09-15 at 18:45 +0200, Jack wrote:
Hello Roman,
First, you should try with [text3d] instead of [text2d], on my configuration, [text3d] is faster.
You right about [text3d] being faster. It's even a lot faster, but also dead ugly. I prefer the rendering result of [text2d]. I don't understand what the difference between those is, actually. Does [text3d] render the text onto a texture on a plane? Does [text2d] render the font as 3d vector?
With the default settings, [text3d] (if i remember right) create a texture for anti aliasing. So you can change anti aliasing with the message "alias". If you send [alias 0(, you work with vertices (if i am right here again), then you can ask to your driver to use anti- aliasing, or not.
I'll look into anti-aliasing settings. Thanks.
About single buffer mode. Did you send à [0( to the [gemhead] at startup ?
Yes.
Look at the patch attached, everything is ok in 0 logical time. On my side, it is strange that i need to send 2 [bang(s to [gemwin] to clear the buffer.
Your patch works for me, too, as you probably intended it to work. What I want is actually the buffer to be cleared before each step, so that the result looks similar to double buffer mode, where only one word appears at the time.
See attached patch. I get only a blank screen and occasionally a single word appearing. It works somewhat more reliable when I insert a [delay 50] between [t b b b] and [gemhead].
OK. see patch attached. It seems to work in 0 logical time. The 'bang' to clear the buffer is sent just after the 'bang' sent to gemhead (it is weird, and i can't remember if the behavior was like this before ?).
Ah.. it didn't occur to me to try this. Thanks!
So yes, it could be a bug because now to clear the buffer, you need to :
- send a bang to gemwin
- send a bang to gemhead
You mean the reversed order, right?
Roman
Le 16/09/2016 à 10:08, Roman Haefeli a écrit :
On Thu, 2016-09-15 at 23:52 +0200, Jack wrote:
Le 15/09/2016 à 20:58, Roman Haefeli a écrit :
On Don, 2016-09-15 at 18:45 +0200, Jack wrote:
Hello Roman,
First, you should try with [text3d] instead of [text2d], on my configuration, [text3d] is faster.
You right about [text3d] being faster. It's even a lot faster, but also dead ugly. I prefer the rendering result of [text2d]. I don't understand what the difference between those is, actually. Does [text3d] render the text onto a texture on a plane? Does [text2d] render the font as 3d vector?
With the default settings, [text3d] (if i remember right) create a texture for anti aliasing. So you can change anti aliasing with the message "alias". If you send [alias 0(, you work with vertices (if i am right here again), then you can ask to your driver to use anti- aliasing, or not.
I'll look into anti-aliasing settings. Thanks.
About single buffer mode. Did you send à [0( to the [gemhead] at startup ?
Yes.
Look at the patch attached, everything is ok in 0 logical time. On my side, it is strange that i need to send 2 [bang(s to [gemwin] to clear the buffer.
Your patch works for me, too, as you probably intended it to work. What I want is actually the buffer to be cleared before each step, so that the result looks similar to double buffer mode, where only one word appears at the time.
See attached patch. I get only a blank screen and occasionally a single word appearing. It works somewhat more reliable when I insert a [delay 50] between [t b b b] and [gemhead].
OK. see patch attached. It seems to work in 0 logical time. The 'bang' to clear the buffer is sent just after the 'bang' sent to gemhead (it is weird, and i can't remember if the behavior was like this before ?).
Ah.. it didn't occur to me to try this. Thanks!
So yes, it could be a bug because now to clear the buffer, you need to :
- send a bang to gemwin
- send a bang to gemhead
You mean the reversed order, right?
What i expected to clear the buffer is to send a bang to gemwin (and only that). I just verified with the GEM: ver: 0.93.git 374f713, and it worked like that before. ++
Jack
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Jack -
Roman Haefeli