discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obscure timing issue


From: Fred Kiefer
Subject: Re: Obscure timing issue
Date: Fri, 12 Dec 2008 21:24:36 +0100
User-agent: Thunderbird 2.0.0.18 (X11/20081112)

Wolfgang Lux wrote:
> Fred Kiefer wrote:
> 
>> The bigger issue is that the redraw takes so long. Here it could be that
>> we draw too much, but it could also be that we just flush too much over
>> to X. The first issue should be simple to detect, we just need to put a
>> write statement before the call to drawRect: in NSView and see whether
>> we try to do too much here. The second issue is a bit harder, here we
>> need to start off in NSWindow flushWindow and try to understand that
>> method as well as the draw rectangle handling in NSView and what the
>> graphics context does when flushing.
> 
> I've now had a look at that, too. Thanks to your hint with drawRect:,
> it looks like the NSBrowser in the open panel is causing the main data
> traffic. At first, I was suspecting that the browser redraws itself as
> it resigns key view in favor of the clicked button. However, it looks
> like the browser redraws itself also if it isn't key view. For instance,
> if I shift the key view via the tab key, the browser appears to be
> redrawn each time the key view changes.
> 


I just added a dummy [NSBrowser setNeedsDisplayInRect:] method to set a
breakpoint there and this is what I got:

reakpoint 1, -[NSBrowser(Private) setNeedsDisplayInRect:] (
    self=0x8482960, _cmd=0xb7f12160, invalidRect=
        {origin = {x = 0, y = 0}, size = {width = 368, height = 286}})
    at NSBrowser.m:3233
3233        [super setNeedsDisplayInRect: invalidRect];
(gdb) bt
#0  -[NSBrowser(Private) setNeedsDisplayInRect:] (self=0x8482960,
    _cmd=0xb7f12160, invalidRect=
        {origin = {x = 0, y = 0}, size = {width = 368, height = 286}})
    at NSBrowser.m:3233
#1  0xb7db7293 in -[NSView _setNeedsDisplay:real:] (self=0x8482960,
    _cmd=0xb7f12428, n=0x8104138) at NSView.m:2605
#2  0xb7db73da in -[NSView setNeedsDisplay:] (self=0x8482960,
    _cmd=0xb7ea3038, flag=1 '\001') at NSView.m:2632
#3  0xb7ca5489 in -[NSControl updateCell:] (self=0x8482960,
    _cmd=0xb7e77780, aCell=0x8348db8) at NSControl.m:688
#4  0xb7c274e6 in -[NSActionCell setStringValue:] (self=0x8348db8,
    _cmd=0xb7e8d280, aString=0xb7e8c3d4) at NSActionCell.m:232
#5  0xb7c6733c in -[NSBrowser drawTitle:inRect:ofColumn:] (
    self=0x8482960, _cmd=0xb7e8d270, title=0xb7e8c3d4, aRect=
        {origin = {x = 0, y = 265}, size = {width = 182, height = 21}},
    column=0) at NSBrowser.m:1459
#6  0xb7c67287 in -[NSBrowser drawTitleOfColumn:inRect:] (self=0x8482960,
    _cmd=0xb7e8d3c8, column=0, aRect=
        {origin = {x = 0, y = 265}, size = {width = 182, height = 21}})
    at NSBrowser.m:1444

Looks like the change I made a few months ago to fix a segmentation
fault when the shared titlecell of the class NSBrowser was still
pointing to a released object is causing this.

Should be fixed in SVN by now.

Fred




reply via email to

[Prev in Thread] Current Thread [Next in Thread]