After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606378 - gdk doesn't handle non-main thread rendering on Quartz
gdk doesn't handle non-main thread rendering on Quartz
Product: gtk+
Classification: Platform
Component: Backend: Quartz
Other Mac OS
: Normal critical
: ---
Assigned To: gtk-quartz maintainers
Depends on:
Reported: 2010-01-08 07:57 UTC by Arc Riley
Modified: 2013-05-03 23:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

example code of described bug (87.81 KB, application/octet-stream)
2010-01-08 09:36 UTC, Arc Riley
test code translated into C for reference (4.21 KB, application/octet-stream)
2010-02-26 22:07 UTC, Kristian Rietveld
better attempt. (4.20 KB, text/x-csrc)
2010-02-27 08:55 UTC, Kristian Rietveld

Description Arc Riley 2010-01-08 07:57:43 UTC
Only white squares appear when all rendering is done in a non-main thread.  In my test, gdk_init and all gdk/drawing functions are done in a single thread.  Windows (the white squares) can be resized, and the white squares change size accordingly, but nothing (including the window title/decoration) is rendered.  The same code runs perfectly on linux and windows.

GDK version 2.18.2 compiled via jhbuild on Jan 7

detachDrawingThread may be needed on the main thread

"If you do any drawing from a secondary thread, you must flush your drawing calls manually. Cocoa does not automatically update views with content drawn from secondary threads, so you need to call the flushGraphics method of NSGraphicsContext when you finish your drawing. If your application draws content from the main thread only, you do not need to flush your drawing calls." has more information on this subject
Comment 1 Arc Riley 2010-01-08 09:36:03 UTC
Created attachment 151026 [details]
example code of described bug
Comment 2 Arc Riley 2010-01-08 09:44:55 UTC
As requested in IRC, further details and example code

This code renders and reconfigures three windows in various ways.  The mainloop with the default context is running in a background (non-main) thread and all rendering in that same thread.  The main thread spends it's entire time in the first "init" block, sleeping most of the time.

On Linux and windows, the windows are black and have a proper title.  Events are outputted as print statements to console.

On OSX, where the windows would be rendered are white rectangles of the same size the windows are expected to be.  The resize events in the script run as they do in Linux, changing the size of the white rectangles.  No title, window buttons, or window decorations are shown.  Events are processed as they are on Linux, outputting text to the console to demonstrate that they are working.  You can even click-drag the top of these white rectangles to drag the windows which generates events as they would normally.

This may be as simple as a missing NSGraphicsContext.flushGraphics call which, as already stated, is only required when rendering from a non-main thread.

To build this:
tar jxvf bug-606378-example.tar.bz2
cd bug-606378-example
python waf configure
python waf build

Waf is included in this tarball so it is not needed but valac (part of the Vala package) is needed to compile the Genie source code (
Comment 3 Arc Riley 2010-02-25 04:52:36 UTC
Comment 4 Tor Lillqvist 2010-02-26 08:41:03 UTC
Arc, this isn't some web forum, no use pinging. Did somebody promise you that you would get a quick and effective response by filing a bug?
Comment 5 Arc Riley 2010-02-26 19:43:24 UTC
Yes, on the IRC channel.  I dedicated a night writing the code to demonstrate this bug, if that was only to watch the ticket sit for months in the tracker I will be less inclined to contribute this amount of effort in the future.
Comment 6 Paul Davis 2010-02-26 20:09:56 UTC
sad to say, but if you're using GTK on OS X (the native backend) (as I am) then you'll need to get used to the idea that *you* are the developer. although from time to time someone else will have some instant insight into a bug on OS X, there is basically no "team" of OS X backend hackers - things get fixed on an as-needed basis by those who need them. its not very nice, but its the way it is.
Comment 7 Arc Riley 2010-02-26 20:16:43 UTC
What is the point of filing bug reports and writing test code if nobody intends to handle them?

I would like to make a constructive suggestion that components of the Gnome framework which have nobody actively maintaining them be marked as such so false expectations are not given and the reputation of the entire Gnome project isn't tarnished by it.
Comment 8 Kristian Rietveld 2010-02-26 20:23:44 UTC
(In reply to comment #7)
> What is the point of filing bug reports and writing test code if nobody intends
> to handle them?

There are absolutely people that want to handle such reports.  But as you might know there are in the thousands of bug reports on GTK+/GDK in this bugzilla, most of which have been open for much longer than the two months this bug has been open, so things will not at all be handled instantly.  People working on this project are mainly volunteers, there is no 24h service guarantee.

We do appreciate the test code that has been submitted.  What has held things back (and this is also something Tor mentioned earlier) is that the testcase is not trivial to build (I don't have the entire vala/genie toolchain compiled) and not written in C.  I am looking into rewriting the test case into C now.
Comment 9 Arc Riley 2010-02-26 21:20:39 UTC
Vala/Genie compiles to C so a rewrite should not be necessary, if you build on a linux system the .c file can be copied out of the build directory.

I don't think anyone expects 24 hour service.  I do think there is a certain level of social agreement; your developers find benefit in receiving detailed bug reports from users, which in this case are other project maintainers who have their own projects to handle, and we benefit by not having to learn the internals of all our dependencies such that we can fix bugs as we find them.

I have no issue if the GDK port to OSX is in an "unmaintained" state; if I was told this from the start I would have invested the time to learn the internals myself and add the few function calls Apple's docs specify are needed.  Instead, I was given an expectation that all that was needed was a clear example of the bug and that it would be resolved, but now two months later our code still doesn't work on OSX and our userbase limited by it.

I am thus complaining not about a lack of volunteer developer time, but lack of clarity and false expectation.  I have encountered similar problems in other areas of the Gnome developer community and much more frequently than any other free software project.  

Thanks for the time and effort you're putting into this issue now, our users would very much appreciate being able to run our next release on OSX.
Comment 10 Paul Davis 2010-02-26 21:27:49 UTC
arc, i'm telling you as clearly as i can that despite the good work that kristian and others (i'll include myself there, on occasion), you should, for all practical purposes, consider the OS X backend unmaintained. That doesn't mean it is broken irreperably; it doesn't that nobody else will ever act on your bug reports. but ... the core of the GTK development team doesn't work on OS X, they don't develop on OS X, they don't have access to OS X and has been repeatedly demonstrated during the 2-3 years that i've been developing with the OS X native backend, its considered entirely acceptable to break the build process and/or functionality of the OS X backend because of some "greater goal".

i suspect that people would dispute my use of the term "unmaintained", and to a certain extent they have a point. but in practical terms, the fact that we have a backend that has been unbuildable out of git with the recommended tools for some time now just points to the wider experience: there is almost nobody working on bugs in the OS X backend, and those you encounter stand at least an 80% probability that you will have to fix them yourself. 

i say all this as the lead developer of one of the largest GTK projects around, and one of the few that actually ships prebuild OS X binaries. GTK has been good for us, but the OS X experience, the fact that its even viable for us to use GTK native on OS X has been very, very reliant on the fact that every so often i have to get down and dirty in the backend and fix lots of code.
Comment 11 Kristian Rietveld 2010-02-26 22:07:49 UTC
Created attachment 154805 [details]
test code translated into C for reference

Already translated the test code into C, so here it is for later reference.  I haven't tried this translated test on Linux yet.

On my Mac, it seems that the GDK backend is not handling any event nor doing any drawing.  From a first sight it looks like this is a little more complicated than a missing flush.  Window movement and resizing probably works fine because this is handled by the Mac window manager and does not go through the GDK event handling.
Comment 12 Kristian Rietveld 2010-02-27 08:55:00 UTC
Created attachment 154812 [details]
better attempt.
Comment 13 Javier Jardón (IRC: jjardon) 2010-02-27 15:42:47 UTC

Only point that you have [1] with direct links to quartz bugs.
Also, there is a OSX [2] page in the wiki, maybe It needs an update?

Hope helps

Comment 14 Kristian Rietveld 2010-02-27 16:53:10 UTC
(In reply to comment #13)
> Only point that you have [1] with direct links to quartz bugs.

I am aware of that, but I was already using my own bugzilla links bookmarked in my browsers.

> Also, there is a OSX [2] page in the wiki, maybe It needs an update?

It was updated end of January this year, so roughly a month ago.
Comment 15 Kristian Rietveld 2010-02-27 17:09:19 UTC
I have investigated this now and the main problem is that Cocoa does not support event handling in any thread other than the main thread (I did not know about this limitation before).  In the Cocoa system, all events are sent to the main thread (the first thread existing in the process) and there is no way to change this.  In the test code, GDK is initialized and runs the GDK main loop in a secondary thread.  Although the connection with the window server is set up in the secondary thread, all events are still sent to the main thread.  Because the main thread does not run an event handling loop, nothing will happen.

Linux/X11 does not have such a limitation.  Neither does GNUStep.  I can't say much about Windows.

Unfortunately, I think this limitation of Cocoa makes it impossible for GTK+ to support initialization and event handling in a secondary thread on native Mac OS X.  We should update the documentation to reflect this.

The events that are received by the test code are events synthesized by GDK itself (these are delivered just fine) and are not based on an event coming from the windowing system.  The problem is that there is no way to receive and process events from the windowing system in this set up.
Comment 16 John Ralls 2013-05-03 23:46:17 UTC
Documentation updated in master; note also that threading in Gdk is deprecated as of 3.6.0.