Re: Obscure timing issue

[Fred Kiefer]

Now that the main issue is solved (will there be a commit soon? I expect
that this may also resolve the cursor issue we sometimes get) let's turn
to the other two problems that Wolfgang pointed out in his mail.

There is the GSTheme class which wastes time looking for non existing
tiles. Here I would suggest that we split up the class. Have the
standard theme class that exactly does what used to be in the gui
drawing code. No bells, no whistles. And a subclass of that that
supports tiling and other fancy theming methods. When somebody writes
her own theming class, she may decide which of these two classes to
inherit from. That way we wont have much overhead in gui through themes.
Any objection to that change?

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 will try to work on that later today,
Fred

Wolfgang Lux wrote:
> Richard Frith-Macdonald wrote:
> 
>> Ah ... so if I understand correctly, you are saying that the X library
>> checks and reads from the socket at times *other* than when we call
>> XPending() in the handler which deals with run loop events.  Thus
>> there is a window between us checking for pending events and us
>> telling the runloop to watch the socket, in which the x library can
>> read the events we are expecting from the socket.
> 
> Indeed, this is what happens. I guess the code which highlights the
> button (rather redraws the window, but that is another issue) is
> requesting some information from the server in this particular case.
> 
>> I think there is a possible workaround for this in our runloop code in
>> gnustep-base ...
>> As well as the -receivedEvent:type:extra:forMode: method that the
>> backend code uses to handle events, it can also implement the
>> -runLoopShouldBlock: method to tell the run loop how to behave before
>> doing the select/poll.
>>
>> So it could be something like:
>>
>> - (BOOL) runLoopShouldBlock: (BOOL*)trigger
>> {
>>   *trigger = YES;    //  Should trigger this event
>>  if (XPending(dpy) > 0)
>>     {
>>       return NO;    // Don't block
>>     }
>>   return YES;
>> }
> 
> I gave it a quick try and it solves issue. Thanks Richard.
>