brennan@rtp.dg.com (Dave Brennan) (08/09/90)
This is a rather simple question, I just don't know if the answer is all
that simple, or what the answer is. For those of you who don't know, Motif
has a scrolled window widget which manages to perform scrolling by moving a
(usually) larger window (in the Xlib sense) around inside a smaller
viewport window. The larger window is a child of the viewport so it is
clipped to the viewport window.
I need to decide if I should use this widget to do scrolling or if I should
use a fixed window without the viewport. Using the scrolled window has the
advantage that I need only handle vanilla expose events - because the
server is moving the window it copies the visible area and generates expose
events (rather than graphics expose events) for areas that have to be
redrawn. If I do the scrolling in my code I'll have to take care of the
copying (via XCopyArea) and graphics expose events as well.
However, I get the feeling that there may be some drawbacks to using the
Motif scrolled window as opposed to handling the scrolling directly. I've
got both ways working and the scrolled window appears to be faster, but I
still have optimizations to make to my code. I sure would appreciate it if
I could get some ideas about which method to use.
Thanks!
|\
Dave Brennan | \____oo_ brennan@rtp.dg.com
=========================================((__| /___> ...rti!dg-rtp!brennan
User Interfaces, Data General | // daveb@rpitsmts.bitnet
Research Triangle Park, NC |// Phone: (919) 248-6330mouse@LARRY.MCRCIM.MCGILL.EDU (08/14/90)
> [...] Motif has a scrolled window widget which manages to perform > scrolling by moving a (usually) larger window (in the Xlib sense) > around inside a smaller viewport window. The larger window is a > child of the viewport so it is clipped to the viewport window. > I need to decide if I should use this widget to do scrolling or if I > should use a fixed window without the viewport. > However, I get the feeling that there may be some drawbacks to using > the Motif scrolled window as opposed to handling the scrolling > directly. I've got both ways working and the scrolled window appears > to be faster, but I still have optimizations to make to my code. I am not familiar with the widget in question. However, a couple of potential problems come to mind anyway.... If the server maintains backing-store for the child window, you'll be eating up a lot of possibly scarce server-side memory unnecessarily. If there's lots of stuff to scroll, the child window may try to be larger than 65535 pixels[%], which will break badly. [%] I know the value is 16 bits. I think it's unsigned (sizes generally are); if it's signed, the limit is instead 32767. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu