|
From: | Andreas Höschler |
Subject: | Re: GNUstep slowness while drawing |
Date: | Wed, 30 Apr 2008 12:18:11 +0200 |
Hi Fred,
Hi Fred,For a qick test I changed all occurances of distantFuture to distantPast in NSApplication.m. This had no obvious effect, neither good nor bad. Drawing (event handling) is still (far too) slow!? Any more ideas?Andreas Höschler wrote:Hi all, I have a view subclass with - (void)mouseDown:(NSEvent *)theEvent {NSPoint locA = [self convertPoint:[theEvent locationInWindow] fromView:nil]; BOOL shiftPressed = (([theEvent modifierFlags] & NSShiftKeyMask) > 0);BOOL keepOn = YES; BOOL hasDragged = NO; while (keepOn) {theEvent = [[self window] nextEventMatchingMask:NSLeftMouseUpMask | NSLeftMouseDraggedMask];switch ([theEvent type]) { case NSLeftMouseDragged: {NSPoint locB = [self convertPoint:[theEvent locationInWindow] fromView:nil]; NSSize offset = NSMakeSize(locB.x - locA.x, locB.y - locA.y);NSRect oldRect = _selectionRect; _selectionRect.origin = locA; if (offset.width < 0) { _selectionRect.origin.x = locB.x; offset.width = -offset.width; } if (offset.height < 0) { _selectionRect.origin.y = locB.y; offset.height = -offset.height; } _selectionRect.size = offset; _selecting = YES;[self setNeedsDisplayInRect:NSUnionRect(_selectionRect, oldRect)];hasDragged = YES; } break; case NSLeftMouseUp: { keepOn = NO; } break; default: break; } } } - (void)drawRect:(NSRect)rect { [super drawRect:rect]; if (_selecting) { [[NSColor grayColor] set]; NSFrameRect(_selectionRect); } }This draws a rectangle following the mouse until the user releases the mouse button. On MacOSX the rectangle follows the mouse instantly. Under GNUstep I see a significant delay. Dragging rectangles makes no fun there. Any idea why this is so slow? This of course has nothing to do with rectangles in special but with slow drawing code in general. In my app I want to drag objects around with the mouse. This works under GNUstep and MacOX but on GNustep it is almost too slow to be usable. Is this a known (may be even already improved) issue? My GNUstep tree is already a year old. :-)Most likely the slow drawing speed you see in GNUstep has nothing to do with the drawing itself, but with the event handling in GNUstep. The window will just not get a chance to redraw itself.One possible reason for this may be that in[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] we handle an expiration date of nil different from Cocoa. There distantPast is used while we use distantFuture, resulting in the loop to wait until the next event happens.As I am no expert in this area, I would like to get some comments from other developers before changing this code. That change may result in the need to adopt a lot of places that rely on the old behaviour.As this simple change isn't working, I will need a stripped down version of your application to reproduce the issue.
While preparing the stripped down application I figured out that this has nothing to do with event handling but is indeed a drawing problem. The stripped down version (subclass of NSView) worked perfectly also under GNUstep. My ObjectBrowserView was actually a subclass or NSImageView since I wanted to have a background image. :-) Now this NSImageView was setup with [_platformObject setImageScaling:NSScaleToFit]. This turned out to be the problem. After adding
#ifndef __APPLE__ - (void)setImageScaling:(NSImageScaling)image { [super setImageScaling:NSScaleNone]; } #endifto my NSImageView subclass the performance problem was gone. Now I have a rather ugly blue frame around the image but I can at least reasonably select objects now which is much more important.
On MacOSX (10.2.8) I see no performance problem even with NSScaleToFit. However, I can live with this solution.
Thanks a lot! Regards, Andreas
[Prev in Thread] | Current Thread | [Next in Thread] |