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 >>> >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/l >>> istinfo/pd-list >>> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis >> tinfo/pd-list >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list
text_single_buffer.pd
Description: application/puredata
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
