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

[Jack]

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 :
1) send a bang to gemwin
2) 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 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
>>
>>
>> _______________________________________________
>> 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: 1659 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160915/1fff2f22/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/1fff2f22/attachment.sig>