bugGNUstep - Bugs: bug #26535, user created NSImage not...


You are not allowed to post comments on this tracker with your current authentication level.

bug #26535: user created NSImage not displaying properly

Submitted by:  Scott Christley <schristley>
Submitted on:  Mon 11 May 2009 10:28:28 PM UTC  
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Ready For Test
Privacy:  Public Assigned to:  Fred Kiefer <FredKiefer>
Open/Closed:  In Test

Sat 10 Feb 2018 08:44:50 AM UTC, comment #5:

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.

Yavor Doganov <yavor>
Fri 09 Feb 2018 09:00:31 PM UTC, 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.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Fri 09 Feb 2018 02:01:32 PM UTC, comment #3:

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)

Yavor Doganov <yavor>
Sat 01 May 2010 04:46:49 PM UTC, comment #2:

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.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Wed 27 May 2009 07:19:44 PM UTC, 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.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Mon 11 May 2009 10:28:28 PM UTC, original submission:
  • 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.

Scott Christley <schristley>


Attached Files
file #43212:  gui.patch added by yavor (876B - text/x-patch)
file #43213:  back.patch added by yavor (712B - text/x-patch)
file #18126:  ImageTest.tgz added by schristley (47KiB - application/x-gzip - Test application showing image problems)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by yavor (Updated the item)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by schristley (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-09 FredKiefer StatusConfirmed => Ready For Test
        Open/ClosedOpen => In Test
    2018-02-09 yavor Attached File- => Added gui.patch, #43212
        Attached File- => Added back.patch, #43213
    2009-05-27 FredKiefer StatusNone => Confirmed
        Assigned toNone => FredKiefer
    2009-05-11 schristley Attached File- => Added ImageTest.tgz, #18126

    Back to the top

    Powered by Savane 3.3