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

 
 

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

bug #34470: -[NSBitmapImageRep initWithFocusedViewRect:] broken

Submitted by:  julian <julian_>
Submitted on:  Mon 03 Oct 2011 11:51:30 PM UTC  
 
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Fred Kiefer <FredKiefer>
Open/Closed: Closed

(Jump to the original submission 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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_>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by ericw (Posted a comment)
  • -unavailable- added by julian_ (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 13 Oct 2011 07:04:53 AM UTCFredKieferStatusReady For Test=>Fixed
      Open/ClosedIn Test=>Closed
    Thu 06 Oct 2011 11:15:12 AM UTCFredKieferStatusConfirmed=>Ready For Test
      Assigned toNone=>FredKiefer
      Open/ClosedOpen=>In Test
    Tue 04 Oct 2011 01:58:41 AM UTCericwStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1