Re: gtk/quartz ... a tale of nested incompatible event loops

[Paul Davis <paul linuxaudiosystems com>]

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 <stuaxo2 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 <paul linuxaudiosystems com> wrote:

On Mon, May 23, 2016 at 2:07 PM, Sébastien Wilmet <swilmet 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