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 > > > > > > > > _______________________________________________ > > [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
#N canvas 385 144 831 300 10; #X declare -stdlib Gem -stdpath Gem; #X obj 34 13 declare -stdlib Gem -stdpath Gem; #X obj 33 120 gemwin; #X obj 270 187 gemhead; #X obj 270 231 text2d; #X obj 399 96 text sequence my_text; #X obj 311 17 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 399 118 list prepend text; #X obj 399 140 list trim; #X obj 58 95 bng 15 250 50 0 empty empty clear 17 7 0 10 -262144 -1 -1; #X obj 399 162 t b a; #X obj 399 204 f; #X msg 579 151 0; #X msg 399 61 line 0; #X obj 216 114 loadbang; #X msg 216 136 0; #X msg 342 64 step; #X obj 593 113 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 270 209 translateXYZ; #X obj 399 25 loadbang; #X floatatom 399 226 5 0 0 0 - - -, f 5; #X obj 545 21 text define -k my_text; #A set one \; two \; three \; four \; five \; six; #X obj 450 204 - 0.3; #X msg 425 242 font dvsm.ttf; #X msg 58 149 0 \, destroy; #X msg 293 147 1; #X obj 311 37 t b b b; #X obj 147 93 t b b; #X msg 33 69 buffer 1 \, create \, 1; #X connect 2 0 17 0; #X connect 4 0 6 0; #X connect 4 1 12 0; #X connect 4 1 11 0; #X connect 4 1 16 0; #X connect 5 0 25 0; #X connect 6 0 7 0; #X connect 7 0 9 0; #X connect 8 0 1 0; #X connect 9 0 10 0; #X connect 9 1 3 0; #X connect 10 0 17 2; #X connect 10 0 19 0; #X connect 10 0 21 0; #X connect 11 0 10 1; #X connect 12 0 4 0; #X connect 13 0 14 0; #X connect 14 0 2 0; #X connect 15 0 4 0; #X connect 17 0 3 0; #X connect 18 0 12 0; #X connect 21 0 10 1; #X connect 22 0 3 0; #X connect 23 0 1 0; #X connect 24 0 2 0; #X connect 25 0 2 0; #X connect 25 1 15 0; #X connect 25 2 26 0; #X connect 26 0 1 0; #X connect 26 1 1 0; #X connect 27 0 1 0;
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
