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

[Jack]

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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: text_single_buffer.pd
Type: application/puredata
Size: 1436 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160915/9f43c3ae/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160915/9f43c3ae/attachment.sig>