Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!bloom-beacon!iris49.UUCP!pete
From: pete@iris49.UUCP (Pete Ware)
Newsgroups: comp.windows.x
Subject: Was None now XtSetValues
Message-ID: <9012271954.AA07350@iris49.biosym.com>
Date: 27 Dec 90 19:54:36 GMT
References: <9338@adobe.UUCP>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 43

>> In article <3235@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes:
>>I am sure there are some reasons why Xt calls XClearArea
>>instead of just calling the widgets redisplay proc immediately.
>>Whatever they are, they don't seem good enough.

> The benefits of allowing the widget to just redisplay its visible
> parts (if any) were considered to outweigh the cost of the server round trip.
>
> 	-paul asente
> 		asente@adobe.com	...decwrl!adobe!asente

Also, the widget writer is the one that determines if XClearArea() is
called.  If the update is critical and happens frequently (a digital
readout in a complex display that the application controls, for example) the
SetValues() function can update that one portion of the display:

	if (oldWidget->timeBar.start_time != current->timeBar.start_time)
	{
		if (XtIsRealized (current))
		{
			NewTime (current, oldWidget);
			redisplay = FALSE;
		}
		else
		{
			redisplay = TRUE;
		}
	}
	return redisplay;

On the other hand, if it really is a critical, frequently occuring
update, it's better to have a global procedure for the
widget to do the update:

	extern void TimeBarNewTime (Widget timebar, double newtime)

and completely avoid the cost of calling XtSetValues() even at the
cost of making your code dependent on that widget class.

--pete
Pete Ware / Biosym / San Diego CA / (619) 546-5532
uucp:	  scripps.edu!bioc1!pete
Internet: bioc1!pete@scripps.edu