Re: An observation in animate demo.

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>On Sunday 09 May 2004 01:27 pm, Hans-Bernhard Broeker wrote:
>  
>
>>On Fri, 7 May 2004, Daniel J Sebald wrote:
>>    
>>
>>>gnuplot> load 'animate.dem'
>>>      
>>>
>
>  
>
>>> But if I hit return once again in the middle of the demo it
>>>will slow down its redraw rate significantly.
>>>      
>>>
>>I think that's the same old X11 multiple-stream handling problem again.
>>    
>>
>
>Sort of.  I added a time delay deliberately to handle a different
>problem, but this is an example of where it imposes a penalty.
>Let me explain what is going on, and you all can speak up as
>to how you want it handled.
>
>The issue is this.
>
>1) When a plot (or replot) is started, the x11 driver sends a query to
>the X-server asking it some basic information like how big is the
>window and what size is the font being used.  This allows much better
>plot layout. Because of this the x11 layout is much nicer in version 4,
>and the information is needed to support enhanced text mode for x11.
>
>2) X11_waitforinput() now waits for the X-server to reply.
>
>3) If terminal input comes in while it is waiting, X11_waitforinput() wakes
>up, notices that it isn't ready to handle new terminal input yet, and then
>loops back to the loop to wait again for the X-server to reply.
>
>4) Problem #1 is that we don't want to read the terminal input at this
>point because that would cause characters to be lost.  That's
>what it used to do, and there were lots of complaints.
>
>5) Problem #2 is that once there is terminal input pending, the select()
>call returns immediately every time through the loop, so we sit there
>burning CPU cycles like mad until the X-server finally responds.
>There were complaints about this also.
>
>6) So as a compromise, I put in a 1 second time delay before going back
>to the top of the loop and the select() call.  
>

Well, actually, this makes the likelihood of a character loss much 
smaller.  There could still be a problem if for some reason the x11 
queries take more than a second, say the system is off doing a lengthy 
hard drive access.  Is this correct?

>Digression: I also added a maximum number of times through the loop,
>so that if the X-server never responds (should only happen in the case
>of a serious error, perhaps  DISPLAY set to an incorrect value) there
>is still a maximum time elapsed before gnuplot returns to accepting
>terminal input.  Even more recently I figured out how to allow ctrl-C to
>interrupt in the case of a jammed X-server, so this maximum loop count
>is no longer strictly necessary but it doesn't by itself hurt anything.
>
>7) In the case of a real X-11 error, like a bad network connection, the
>1 second delay is a small price to pay for handling a bad connection
>without locking up the CPU.  In the case of a loop, however, even with
>a fully responsive X-server the unexpected terminal input causes a
>1 second delay every time through the loop. I agree this is bad.
>
>Possible fixes:
>
>Make the time delay much smaller.  On platforms with usleep()
>it could be some number of microseconds rather than a full second.
>As I recall, I originally I had usleep(100) but I switched to sleep(1)
>when I realized that not all platforms provide usleep().
>
 >

>Don't send the font+window size query if mousing is disabled.
>Then in the case of an animation loop you could just disable the
>mouse before entering the loop, and re-enable it afterwards if
>needed.   I don't like this because if your original plot has 
>mousing disabled, you will never get the info about window or
>font size.  OTOH perhaps replot could handle this differently than
>plot (I'd have to look to see whether X11_waitforinput() can
>tell the difference). This would actually speed up the animation loop,
>since even if the X-server is responding normally the query/response
>cycle is kind of slow compared to everything else.
>
 >

>Introduce a new command to toggle the query/response feedback.
>The internal mechanism is already in place, because some time 
>back I added this as a command line option   'gnuplot -nofeedback'
>in order to allow people with problems to turn it off altogether.
>I don't like this because it's a command that would be specific to
>X11, and would just clutter up the command set.
>

I know developers are against this.  But the issue of being X11 specific 
doesn't bother me.  I'd say trust your instinct for what to do, but wait 
if or until you have an nice solution in mind for which you won't mind 
breaking the current set up.

>I tentatively propose to modify the time delay to be
>#ifdef HAVE_USLEEP
>	usleep(100);
>#else
>	sleep(1);
>#endif
>

Not completely comfortable with that for the simple fact that it is 
increasing the likelihood of a discarded character.  However, at this 
point coming off the 4.0 release I think this would be a reasonable 
solution and then maybe put mouse mods on hold for a while because other 
things might be worth adding and testing.

Am I right in thinking that now that the developers have put a lot of 
work into a stable 4.0 after a long long duration of developments, it 
might be easier to get successive versions ready?  But not too often.  
:-)  So perhaps some smaller changes would be in order.  Coming up with 
a target date for a next release candidate, say 1 year from now, might 
be good.  Also, establishing and prioritizing some general goals for 
that release would help.  (I could offer some if people want to start 
discussing that.)

>I am open to feedback about whether 'unset mouse' should
>disable the size+font query altogether in the case of a replot,
>or the question of having an explicit command to disable it.
>

Eh.  A command the user has to know when and how to apply and it may 
behave differently on different platforms?  Nah.

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/