kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (02/14/91)
Philosophically speaking, if the widgets we are writing do lots of Xlib stuff (XDrawLine, XDrawImageString etc.) where is it appropriate to do an XFlush or an XSync? Within the widget internals? Or out in the application? Does anyone really care? -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov As of right now, I'm in charge here now... Alexander Haig. Voodoo Economics, that's what it is, voodoo economics. George Bush
pete@iris49.UUCP (Pete Ware) (02/15/91)
Philosophically speaking, neither a widget nor an application should ever call XSync or XFlush. XFlush gets called from the event loop or when the data buffer is full. Things usually refresh fastest if you never explicitely XFlush. There are exceptions, such as scrolling, that may make you want to call XSync, but generally avoid it. --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 uucp: scripps.edu!bioc1!pete Internet: bioc1!pete@scripps.edu
klee@wsl.dec.com (Ken Lee) (02/15/91)
In article <1991Feb13.225240.547@thyme.jpl.nasa.gov>, kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: |> Philosophically speaking, if the widgets we are writing do lots |> of Xlib stuff (XDrawLine, XDrawImageString etc.) where is it appropriate |> to do an XFlush or an XSync? Within the widget internals? Or out in |> the application? I don't know about philosophically, but practically speaking, the application is not likely to have enough information to manage this. In most cases, if control gets back to the application, a flush has probably happened automatically, anyway. If you really have to flush, the widget's expose procedure is probably the only useful place to do it. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (02/16/91)
In article <9102141621.AA03712@iris49.biosym.com> pete@iris49.UUCP (Pete Ware) writes: >Philosophically speaking, neither a widget nor an application should >ever call XSync or XFlush. XFlush gets called from the event loop or >when the data buffer is full. Things usually refresh fastest if you >never explicitely XFlush. > I tend to disagree with this, and cite the follow examples: An application that performs computationally intensive routines, and wants to manage a popup dialog notifying the user to wait. If the buffer is not flushed with either an XFlush or XSync, there is no guarantee that the popup will be mapped. Using XFlush or XSync after managing will ensure this. This example has been a frequent topic in c.w.x.m. Our application creates and manages hundreds of widgets as part of a psuedo real-time status display. In early testing, we discovered that after managing, while awaiting data to display, many widgets weren't drawn until after a (considerable) delay. The strategic placement of an XSync guaranteed the timely drawing of all the widgets that had been managed. As we are using Motif, we can't go adding to these widgets, but for the widgets we are writing, we have a clean slate. So to re-iterate my original question: If we have a widget that is internally doing a large amount of drawing, where should we do the XFlush/Xsync, inside or outside the widget? -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov As of right now, I'm in charge here now... Alexander Haig. Voodoo Economics, that's what it is, voodoo economics. George Bush
pete@iris49.UUCP (Pete Ware) (02/19/91)
I still maintain that as a philisophical issue, neither an application nor a widget should call XFlush() or XSync(). kaleb> An application that performs computationally intensive kaleb> routines, and wants to manage a popup dialog notifying the user kaleb> to wait. If the buffer is not flushed with either an XFlush or kaleb> XSync, there is no guarantee that the popup will be mapped. kaleb> Using XFlush or XSync after managing will ensure this. This kaleb> example has been a frequent topic in c.w.x.m. In this case, even an XFlush or XSync will not guarantee the popup is displayed. You are assuming that the expose event will occur closely enough after a XMapWindow that the XSync will get the expose -- it isn't true. To do this right you need to enter into an event loop until the popup can say that yes, I'm done drawing (it needs to do an XFlush). But this is definitely a special case. kaleb> As we are using Motif, we can't go adding to these widgets, but for kaleb> the widgets we are writing, we have a clean slate. So to re-iterate kaleb> my original question: If we have a widget that is internally doing kaleb> a large amount of drawing, where should we do the XFlush/Xsync, inside kaleb> or outside the widget? I'd probably hide inside the widget just because one should minimize how dependent an application is on the implementation. (It's also a pain later when you realize the call the XFlush() is a mistake and you have to go traipsing all over your code to remove it). But to try to convince you not to do it: Do you use stdio? Do you turn off all buffering for each stream? Do you even call fflush()? Think of XFlush() as being equivalent. You're sending a message to stderr so you want it to appear right away, just like creating a popup to warn the user about something. This means flushing the output is ok. On the other hand, if you are doing lots of output, you probably want it to be as efficient as possible -- just because you _are_ doing lots of output. I also object to using XSync because it (1) forces a round trip to the server; (2) is probably hiding timing errors on the relative fast connection and server that you are doing your development on -- as soon as someone runs your application against a slow server it's going to at best display incorrectly and at worst break. --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 uucp: scripps.edu!bioc1!pete Internet: bioc1!pete@scripps.edu