I’m playing with removing the @synchronized locks in the libpd Obj-C layer since the updates to the libpd ringbuffer seem to be working now.
Long story short, I’m only running into one issue: divide by 0s in g_rtext.c rtext_senditup() when opening a file. It seems that the findx & findy computations on line 215 & 216 fails since the previous glist_fontwidth() & glist_fontheight() calls return 0. Could this be an execution order issue where removing the lock is making something happen earlier than it should? Adding the following before the findx & findy math works as a quick fix to keep the divide by zero error: if (fontwidth <= 0) fontwidth = 1; if (fontheight <= 0) fontheight = 1; I’m wondering if there is a better way to catch this... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
