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

Group
 
 

bug #26535: user created NSImage not displaying properly

Submitter:  Scott Christley <schristley>
Submitted:  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:  FredKiefer
Open/Closed:  In Test
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
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>
Group Member
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>
Group Member
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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    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.13-f8d8.
    Corresponding source code