bugGNUstep - Bugs: bug #23333, -initWithFocusedViewRect: seems to...

Group
 
 

bug #23333: -initWithFocusedViewRect: seems to crash with clipped views

Submitter:  Quentin Mathé <qmathe>
Submitted:  Fri 23 May 2008 05:09:57 PM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 03 Jul 2012 07:27:34 PM UTC, comment #5: 

Has there ever been any progress on this?  It seems as though this might be either fixed or, ultimately, moot since Cairo is the default backend now.

Gregory John Casamento <gcasa>
Group administrator
Thu 26 Jun 2008 12:12:00 AM UTC, comment #4: 

Cairo backend solves my problem, so you're correct it's a art backend issue.

Quentin Mathé <qmathe>
Group Member
Wed 25 Jun 2008 07:55:44 PM UTC, comment #3: 

Changed into a backend bug. I hope this is correct as there was no further feedback.

Fred Kiefer <FredKiefer>
Group Member
Wed 28 May 2008 10:14:41 AM UTC, comment #2: 

I'll give a try to Cairo backend and also see whether the fix for art is easy or not.

Thanks for the reply, Fred.

Quentin Mathé <qmathe>
Group Member
Tue 27 May 2008 10:54:36 PM UTC, comment #1: 

The GSReadRect method in art is rather broken. It does not take the current transformation into account and also creates an image that this one pixel to wide.
Any patch for this will be greatly welcomed.

Fred Kiefer <FredKiefer>
Group Member
Fri 23 May 2008 05:09:57 PM UTC, original submission:  

Ubuntu 7.10
gnustep-base r26119
gnustep-gui r26262
gnustep-back (art) r26014

I use the following method in an NSImage category to take snapshots of views.

// I take care to only pass the visible rect of view as sourceRect
- (void) takeSnapshotFromRect: (NSRect)sourceRect inView: (NSView *)view
{
NSBitmapImageRep *rep = nil;

if ([view window] == nil || [view canDraw] == NO)
{
ETLog(@"WARNING: Impossible to snapshot view %@", view);
return;
}

[view lockFocus];
rep = [[NSBitmapImageRep alloc] initWithFocusedViewRect: sourceRect];
[view unlockFocus];

[self addRepresentation: rep];
RELEASE(rep);
}

It works very well on Cocoa, but I have troubles with it on GNUstep. I often got the following segfaults, here is the end of the stack trace:

#0  0xb70d6d8a in bgra_read_pixels_o (c=0xbf8f1aec, num=134) at blit.m:436
#1  0xb70fe546 in -[ARTGState(ReadRect) GSReadRect:] (self=0x8511f48, _cmd=0xb71089f0, r=
      {origin = {x = 0, y = 0}, size = {width = 580, height = 261}}) at ReadRect.m:132
#2  0xb7097d6c in -[GSContext(NSGraphics) GSReadRect:] (self=0x83deb08, _cmd=0xb7dcc6f8,
      rect={origin = {x = 0, y = 0}, size = {width = 580, height = 261}})
      at GSContext.m:872
#3  0xb7b9b7bb in -[NSBitmapImageRep initWithFocusedViewRect:] (self=0x8451350,
     _cmd=0xb7f22ed8, rect={origin = {x = 0, y = 0}, size = {width = 580, height = 261}})
     at NSBitmapImageRep.m:323
#4  0xb7eec06f in -[NSImage(Etoile) takeSnapshotFromRect:inView:] (self=0x8316160,
     _cmd=0xb7f22ea0, sourceRect=
     {origin = {x = 0, y = 0}, size = {width = 580, height = 261}}, view=0x83e0598)
     at NSImage+Etoile.m:93

I have been able to reproduce it in a relatively simple case which consists of calling this method with an image view, located inside a scroll view, and partially or fully obscured by the clip view. If the image view is fully visible within the scroll view (scrollers disabled), the snapshot doesn't trigger a segfault. On the other hand, if I resize the scroll view to clip the content and get the scrollers enabled then I get a segfault if I try to take a snapshot on this image view. Taking a snapshot on the scroll view seems to be fine though.

I have other cases where I get this crash by taking a snapshot of a table/outline or browser views, but they are more complicated to reproduce. May be that's only one bug since table/outline and browser views are all enclosed inside a scroll view by default (when you use the Gorm provided instances)... Not really sure about that though.

By reading the stack trace, it looks like GNUstep is unable to provide valid data for a view that is clipped even if the view belongs to a window and doesn't report a problem when -lockFocus is called on it. It would be great to have the same behavior than Cocoa but if it's too complicated, I'd like to suggest the method should return a nil image rep in such problematic cases instead of crashing. May be -lockFocus should log a message too...
The Cocoa implementation isn't perfect because it doesn't check for [view window] == nil, it just crashes in a very weird way. -canDraw doesn't help in my test. May be GNUstep could implement this extra check [view window] == nil.

Thanks,
Quentin.

Quentin Mathé <qmathe>
Group Member

 

(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 gcasa (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by qmathe (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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-06-25 FredKiefer CategoryGui/AppKit Backend

    Back to the top

    Powered by Savane 3.13-269c.
    Corresponding source code