[PD] [Gem] Using [text2d] in single buffer mode

Roman Haefeli reduzent at gmail.com
Thu Sep 15 20:58:26 CEST 2016


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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list
> > 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> tinfo/pd-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: text_single_buffer.pd
Type: text/x-puredata
Size: 1660 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160915/8c3d0395/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160915/8c3d0395/attachment-0001.sig>


More information about the Pd-list mailing list