[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
- Re: Obscure timing issue, (continued)
- Re: Obscure timing issue, Richard Frith-Macdonald, 2008/12/10
- Re: Obscure timing issue, Fred Kiefer, 2008/12/10
- Re: Obscure timing issue, Richard Frith-Macdonald, 2008/12/11
- GNUstep themes [Was: Obscure timing issue], Fred Kiefer, 2008/12/11
- Re: GNUstep themes [Was: Obscure timing issue], Richard Frith-Macdonald, 2008/12/12
- Re: GNUstep themes [Was: Obscure timing issue], Andreas Schik, 2008/12/12
- Re: GNUstep themes [Was: Obscure timing issue], Richard Frith-Macdonald, 2008/12/12
- Re: GNUstep themes [Was: Obscure timing issue], Fred Kiefer, 2008/12/12
- Re: Obscure timing issue, Fred Kiefer, 2008/12/10
- Re: Obscure timing issue, Wolfgang Lux, 2008/12/12
- Re: Obscure timing issue,
Fred Kiefer <=