Summary: user created NSImage not displaying properly
Submitted by: schristley
Submitted on: Mon 11 May 2009 06:28:28 PM EDT
Severity: 3 - Normal
Item Group: Bug
Assigned to: None
Discussion Lock: Any
this is just to let you know that I started to investigate these problems.
Sorry for taking so long, but I first was away and then had a lot of other
stuff that needed to be taken care of. On the other hand I really seem to be
the only one to address such issues in GNUstep. We need to change that.
Your bit size is a nice typo, it left me guessing whether you have 32 or 64,
but in reality this isn't that important here.
Thank you for your excellent test application, this clearly shows the
problems. As you pointed out we have two issues, one with scaling and one with
background threads. Up to now I only looked into the first one.
The code at fault is the one in [NSImage
drawInRect:fromRect:operation:fraction:]. In the scaled case we end up using
the NSBitmapImageRep to draw and not the interally created NSCachedImageRep
(line 1157). And at this point the bitmap is empty, so it doesn't really help.
On the other hand, cached images can only draw scaled via a horrible hack (See
NSCachedImageRep draw]. It would be possible to resolve this for the cairo
backend by moving the actual drawing into the backend, but I still need a
solution for the other backends.
Just a short update on this bug. The problem still persists and in the
meantime I also looked into the second issue. At the moment GNUstep isn't able
to do any drawing in a secondary thread. The code fails when it tries to cache
the image rep and cannot find a display server for the current thread.
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 did apply your change in a slightly modified version. When looking at the
gui change I noticed that this will break the whole idea of having the display
server in a thread local variable. SO I made this a normal static variable.
As the original test application now seems to work for me I change the status
of this issue to in test.
Yes, I think this makes sense. My initial version was to check if the current
thread is the main thread but that's useless. Any drawing in secondary
threads occurs after +sharedApplication which sets up the server in the main