Digging further, looks like sys_zoomfontwidth() & sys_zoomfontheight() are 
returning 0 in glist_fontwith()/glist_fontheight().

--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Sep 24, 2016, at 11:20 AM, Dan Wilcox <[email protected]> wrote:
> 
> 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
[email protected]
https://lists.puredata.info/listinfo/pd-dev

Reply via email to