bugGNUstep - Bugs: bug #34470, -[NSBitmapImageRep...

Group
 
 

bug #34470: -[NSBitmapImageRep initWithFocusedViewRect:] broken

Submitter:  julian <julian_>
Submitted:  Mon 03 Oct 2011 11:51:30 PM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 06 Oct 2011 12:05:55 PM UTC, comment #6: 

thanks, i can confirm that the original use case is fixed.

julian <julian_>
Thu 06 Oct 2011 11:15:12 AM UTC, comment #5: 

I added the fix I suggested. As Eric pointed out this wont help with retrieving a changed representation from the image, but should avoid the need of drawing the actual representation in application code.

Fred Kiefer <FredKiefer>
Group Member
Wed 05 Oct 2011 06:42:02 PM UTC, comment #4: 

Hi Fred,
I think that would work, but it would take some work to test it. We really need a test for lockFocus/unlockFocus in GSTest or in the gui test suite. I was thinking of looking at this after the next release, maybe.

There are other differences between GS and cocoa; e.g. on cocoa, -unlockFocus removes all representations from the image, and adds a new representation containing the cache that was created in lockFocus and drawn on.

The background colour drawing code is a mystery to me as well. It's hard to find a clear explanation of what -setBackgroundColor: is supposed to do. I did verify on cocoa that the background colour is not drawn if you load a transparent PNG, set a solid background colour, and then use one of the -drawInRect: methods. Personally, I would be tempted to deprecate the background colour it and ignore it because it doesn't seem to do anything useful/obvious.

Eric Wasylishen <ericw>
Group Member
Wed 05 Oct 2011 05:53:43 PM UTC, comment #3: 

Eric,
I understand that the right thing to do here would be to support graphic contexts based on bitmap data, which is not too hard to do for cairo. But for now wouldn't it resolve the problem to move the line drawing the current representation from _doImageCache: into the end of the if statement in lockFocusOnRepresentation:?
Of course only when repd->original isn't nil.

Perhaps we may be able to remove some of the duplicate background colour drawing in the process as well. This code is very old and although I moved it around quite some times, I still don't fully understand what was intended and what is still needed. When I last rewrote things here, about three years ago, I had to undo a few of my changes later on, as the code doesn't exactly work as expected with all GNUstep backends. This means we have to be extra careful and test a lot.

Fred Kiefer <FredKiefer>
Group Member
Tue 04 Oct 2011 11:54:11 AM UTC, comment #2: 

thanks, workaround works ;-)

julian <julian_>
Tue 04 Oct 2011 01:58:41 AM UTC, comment #1: 

Looks like there are major differences between GS and Cocoa's lockFocus/unlockFocus :-(

Well, GS doesn't draw the image into the cache. It should be reasonably easy to fix.
You can work around it by drawing the image yourself for now, like this:


NSImage *theImg = [[NSImage alloc] initWithContentsOfURL:_url];
NSImageRep *rep = [theImg bestRepresentationForDevice: nil];
[theImg lockFocus];
[rep drawInRect:NSMakeRect(0,0,[theImg size].width, [theImg size].height)];
… rest of the code unchanged.

Eric Wasylishen <ericw>
Group Member
Mon 03 Oct 2011 11:51:30 PM UTC, original submission:  

the following method to obtain the "raw" bytes of a NSImage does work on Cocoa but not on GNUstep (inline posting may eat two obvious asterisks) - the resulting data buffer is all zero:

NSImage *theImg = [[NSImage alloc] initWithContentsOfURL:_url];

[theImg lockFocus];

NSBitmapImageRep *bitmap = [[NSBitmapImageRep alloc] initWithFocusedViewRect:NSMakeRect(0.0, 0.0, [theImg size].width, [theImg size].height)];

[theImg unlockFocus];

char _data = (char )calloc( [theImg size].width 4 [theImg size].height, 1);
memcpy(_data, [bitmap bitmapData], [theImg size].width 4 [theImg size].height);


julian <julian_>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by ericw (Posted a comment)
  • -email is unavailable- added by julian_ (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-10-13 FredKiefer StatusReady For Test Fixed
        Open/ClosedIn Test Closed
    2011-10-06 FredKiefer StatusConfirmed Ready For Test
        Assigned toNone FredKiefer
        Open/ClosedOpen In Test
    2011-10-04 ericw StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code