[bug #26535] user created NSImage not displaying properly

[Scott Christley]

URL:
<http://savannah.gnu.org/bugs/?26535>

Summary: user created NSImage not displaying properly
Project: GNUstep
Submitted by: schristley
Submitted on: Mon 11 May 2009 06:28:28 PM EDT
Category: Gui/AppKit
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

* Scaling of user created images not working.

* Drawing in images in secondary threads not working.

I'm using GNUstep from SVN on Debian 34-bit intel.





_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 11 May 2009 06:28:29 PM EDT Name: ImageTest.tgz Size: 47kB By:
schristley
Test application showing image problems
<http://savannah.gnu.org/bugs/download.php?file_id=18126>

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?26535>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Update of bug #26535 (project gnustep):

Status: None => Confirmed
Assigned to: None => FredKiefer

_______________________________________________________

Follow-up Comment #1:

Hi Scott,

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.





_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?26535>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Follow-up Comment #2, bug #26535 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?26535>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/

[Yavor Doganov]

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/

[Fred Kiefer]

Update of bug #26535 (project gnustep):

Status: Confirmed => Ready For Test
Open/Closed: Open => In Test

_______________________________________________________

Follow-up Comment #4:

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?26535>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #5, bug #26535 (project gnustep):

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
thread.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?26535>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/