Follow-up Comment #3, bug #26535 (project gnustep): I stumbled upon the second issue. Lynkeos does all of its image processing in worker threads so basically it doesn't work at all on GNUstep. I was about to write a similar test application but fortunately I found this bug.
With the attached *surprisingly* trivial patches drawing in secondary threads works at least with the cairo backend. Art and xlib display black rectangles in Scott's test app but that's a general problem because the same happens with the non-threaded variants (only file image is displayed). I haven't tested the opal backend as I can't build the opal library. Lynkeos works only with cairo. There is some flickering when the processed image is being refreshed. With art/xlib I get a weird glibc SIGABRT when it is loading the main XIB file and instantiating objects. I haven't done the equivalent for the woe32 server as I'm not familiar with the code and can't test it anyway. I am not sure at all if this is the right approach and what is the performance penalty. There should be some because XInitThreads enables the X locking mechanism and it must be called unconditionally. I hope this is one small step forward, though. (file #43212, file #43213) _______________________________________________________ Additional Item Attachment: File name: gui.patch Size:0 KB File name: back.patch Size:0 KB _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?26535> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list Bugemail@example.com https://lists.gnu.org/mailman/listinfo/bug-gnustep