GNOME Bugzilla – Bug 606378
gdk doesn't handle non-main thread rendering on Quartz
Last modified: 2013-05-03 23:46:17 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." http://developer.apple.com/mac/library/documentation/cocoa/conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-SW1 has more information on this subject
Created attachment 151026 [details] example code of described bug
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 build/default/src/bug-606378-example 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 (http://live.gnome.org/Genie)
Ping.
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?
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.
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.
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.
(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.
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.
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.
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.
Created attachment 154812 [details] better attempt.
Hello, 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 [1] http://live.gnome.org/GTK%2B/BugzillaLinks [2] http://live.gnome.org/GTK%2B/OSX
(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.
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.
Documentation updated in master; note also that threading in Gdk is deprecated as of 3.6.0.