Hi Fred,
Hi Fred,
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.
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?
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];
}
#endif
to 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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
