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:


  Message sent via/by Savannah

Bug-gnustep mailing list

Reply via email to