Andreas Höschler wrote:
> 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.
Cheers,
Fred
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
|
