The problem I was describing only affects a situation where some code that uses Cocoa (CoreGraphics,really) directly exists in the same process as a gtk/gdk/glib event loop. And it only is a problem if the CG rendering is so slow that the CFRunLoop never idles. This only happens to use on systems with Retina, and appears to be caused by the invocation of a specific function from Apple that seems to be incredibly inefficiently implemented. So unless you're triggering all of these things, I doubt it is the same problem. But ... the basic underlying issue here is that gtk/gdk/glib on OS X is 100%, absolutely dependent on the main CFRunLoop going idle - if it does not go idle, then the gtk main event loop will not run.
On Tue, May 24, 2016 at 5:13 AM, Stuart Axon <stua...@yahoo.com> wrote: > Hi, > For Shoebot we use python with gi.repository, along with > main_iteration + custom drawing with cairocffi, however on the most recent > OSX, when I try and run, nothing is rendered - could this be the same / a > similar issue ? > > S++ > > > > > On Monday, May 23, 2016 7:20 PM, Paul Davis <p...@linuxaudiosystems.com> > wrote: > > > > > > On Mon, May 23, 2016 at 2:07 PM, Sébastien Wilmet <swil...@gnome.org> > wrote: > > On Mon, May 23, 2016 at 01:29:44PM -0400, Paul Davis wrote: > <snip> > > I'm emailing it > > just in case anybody else decides to wade into a complete overhaul of the > > design of the glib event loop on Quartz. > <snip> > > Looks somewhat obscure and low-level. > > > The conditions that led to use needing to do this are obscure. The fix is > definitely low level. But the issue is a design that landed in GTK+ some > years ago (possibly as many as 10 years ago), and is fundamentally > problematic. Replacing a call to some variant of poll() with a call into > the native windowing system's own event loop is ... well, different :) > > > > I think on bugzilla it would have more chances to be read by someone > interested to improve the quartz support in the future. When doing a > complete overhaul, looking at the existing reported bugs seems a good > thing to do. > > > I would say that there is a 90% chance that I will be person to > reimplement things. I wasn't looking so much for someone to fix it for me, > but to see how much moral support I might raise :) > > > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
