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
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
