ado@elsie.nci.nih.gov (Arthur David Olson) (12/05/90)
So now that you've got your system's clock within milliseconds of where you
want it to be, what about the display on your screen? The attached is only a
start; the ftime system call would be needed for a complete job, along with
the code to lead the time by the delay between when the xclock process sends
the bits and when bits appear on screen.
--ado
< From ado Tue Dec 4 23:20:23 1990
< To: xbugs@expo.lcs.mit.edu
< Subject: xclock -analog can be up to a minute behind (with fix)
< Cc: adam@ncifcrf.gov
<
<
< X Window System Bug Report
< xbugs@expo.lcs.mit.edu
<
<
<
<
< VERSION:
< XV11R4 (plus fixes through fix-14)
<
< CLIENT MACHINE and OPERATING SYSTEM:
< Sun 3/60 running SunOS 4.0.3
<
< DISPLAY:
< Sun CG4
<
< WINDOW MANAGER:
< twm
<
< AREA:
< xclock
<
< SYNOPSIS:
< An analog xclock can be up to a minute behind.
<
< DESCRIPTION:
< It rounds time down to the nearest minute; if it does an update at,
< say, 59 seconds past the minute, you lose.
<
<
< REPEAT BY:
< At 50 seconds past the minute, start up an
< xclock -analog -geom 300x300+1+1
< and note the position of the hands
<
< SAMPLE FIX:
< mit/lib/Xaw/SCCS/s.Clock.c: 1.2 vs. 1.3
< *** 1.2/mit/lib/Xaw/Clock.c Tue Dec 4 23:18:10 1990
< --- 1.3/mit/lib/Xaw/Clock.c Tue Dec 4 23:18:11 1990
< ***************
< *** 379,385 ****
< */
< DrawHand(w,
< w->clock.minute_hand_length, w->clock.hand_width,
< ! ((double) tm.tm_min)/60.0
< );
< if(w->clock.Hdpixel != w->core.background_pixel)
< XFillPolygon( dpy,
< --- 379,385 ----
< */
< DrawHand(w,
< w->clock.minute_hand_length, w->clock.hand_width,
< ! (tm.tm_min * 60.0 + tm.tm_sec) / (60.0 * 60.0)
< );
< if(w->clock.Hdpixel != w->core.background_pixel)
< XFillPolygon( dpy,
< ***************
< *** 394,401 ****
< w->clock.hour = w->clock.segbuffptr;
< DrawHand(w,
< w->clock.hour_hand_length, w->clock.hand_width,
< ! ((((double)tm.tm_hour) +
< ! (((double)tm.tm_min)/60.0)) / 12.0)
< );
< if(w->clock.Hdpixel != w->core.background_pixel) {
< XFillPolygon(dpy,
< --- 394,401 ----
< w->clock.hour = w->clock.segbuffptr;
< DrawHand(w,
< w->clock.hour_hand_length, w->clock.hand_width,
< ! (((tm.tm_hour * 60.0) + tm.tm_min) * 60.0 +
< ! tm.tm_sec) / (12.0 * 60.0 * 60.0)
< );
< if(w->clock.Hdpixel != w->core.background_pixel) {
< XFillPolygon(dpy,
< --
< Arthur David Olson ado@elsie.nci.nih.gov
< ADO and Elsie are Ampex and Borden trademarksphilip@beeblebrox.dle.dg.com (Philip Gladstone) (12/06/90)
In article <90392@elsie.nci.nih.gov> ado@elsie.nci.nih.gov (Arthur David Olson) writes:
ado> So now that you've got your system's clock within milliseconds of where you
ado> want it to be, what about the display on your screen? The attached is only a
ado> start; the ftime system call would be needed for a complete job, along with
ado> the code to lead the time by the delay between when the xclock process sends
ado> the bits and when bits appear on screen.
I noticed a similar xclock 'problem'. If you set xclock to update
every second, then it annoyed me that the second hand did not tick 'on
the second' but at some other (non-determinate) time. Unfortunately, I
don't have the sources of xclock so I can't fix it.
--
Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK
Listen three eyes, don't you try and outweird me, I get
stranger things that you free with my breakfast cereal.