etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/18/90)
XtSetValues works by first calling the widget's SetValues Proc. If this routine indicates that the widget should be redrawn, Xt will issue a ClearArea on the whole widget. The widget will not be redrawn until you are back in your Main Event Loop. 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. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
marbru@attc.UUCP (Martin Brunecky) (12/19/90)
In article <3235@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: > >XtSetValues works by first calling the widget's SetValues >Proc. If this routine indicates that the widget should >be redrawn, Xt will issue a ClearArea on the whole widget. > The reason is (likely) to avoid drawing to unmapped widgets, and (likely) to avoid timing related race conditions, and ..... But I have (yet another) reason to grief. Some of my widgets don't create a window, they create an (off-screen) pixelmap. [I see the big WRONG! on your faces]. Such widgets make some things much easier and cleaner, but... I cant' allow ClearArea on Pixmap (BadWindow...), so I have to use couple nasty tricks to get around it. So, while my superclasses "SetValues" can return TRUE, Redisplay!, I'd love to have a way of saying: NO, don't do it! in *my* SetValues. Unfortunatelly, Xt only or-es responses from all SetValues. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
asente@adobe.com (Paul Asente) (12/21/90)
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
pete@iris49.UUCP (Pete Ware) (12/28/90)
>> 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
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/29/90)
In article <9338@adobe.UUCP>, asente@adobe.com (Paul Asente) writes: |> 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 How much of the time is an 'active' widget partially or fully obscured? -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
marbru@attc.UUCP (Martin Brunecky) (01/03/91)
In article <9012271954.AA07350@iris49.biosym.com> pete@iris49.UUCP (Pete Ware) writes: >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; But the solution above does not help if you are subclassing off of something you can't change (Motif widget, for exmaple) and it's SetValues already says redisplay = TRUE. Unfortunatelly, XtSetValues only ORes results of calls to set_values method traversing down the class hierarchy. May be some "special value" of the set_values return (XtSetValues "NEVER") could do the trick in this case .... Note, it sounds like a hack. It is a hack. But the more people start subclassing off of (other people's) widgets WITHOUT modifying those, the more often they will find they have to UNDO (some) results of the superclasses operation (initialize, set_values). And this is just such an "undo". -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
pete@iris49.UUCP (Pete Ware) (01/03/91)
mb> But the solution above does not help if you are subclassing off of
mb> something you can't change (Motif widget, for exmaple) and it's SetValues
mb> already says redisplay = TRUE.
mb> Unfortunatelly, XtSetValues only ORes results of calls to set_values
mb> method traversing down the class hierarchy.
mb> Martin Brunecky {...}sunpeaks!auto-trol!marbru
(303) 252-2499 (sometimes also: marbru@auto-trol.COM )
mb> Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
Yes, it would be nice if we had a little more control in some of the
class traversals but for the large majority of things it isn't needed.
In this particular case, one is probably adding resources that the
parent class does not know about and so a SetValues won't cause a
redisplay. Also, if performance is really that critical, a function
call is a good solution.
--pete
Pete Ware / Biosym / San Diego CA / (619) 546-5532
uucp: scripps.edu!bioc1!pete
Internet: bioc1!pete@scripps.edu