CLIM mail archive
[Prev][Next][Index][Thread]

Screen update and feeling the bits between your toes

    Date: Mon, 14 Oct 1991 06:40 EDT
    From: Peter Paine <p2@porter.asl.dialnet.symbolics.com>

	Date: Fri, 11 Oct 1991 19:44-0000
	From: Scott McKay <SWM@sapsucker.scrc.symbolics.com>

	    Date: Fri, 11 Oct 1991 11:54 EDT
	    From:	Jim Mayer <mayer@wrc.xerox.com>

	    Is there a mechanism within CLIM that would allow me to move areas of
	    screen real estate around without redrawing?  The kind of think I am
	    thinking of is what most terminal emulators do when they insert a new
	    line: rather than redraw the bottom half of the screen, they BITBLT
	    the bottom half down one line height's worth of bits.

	I have a working implementation of "pixmaps" for CLIM 1.0 for both
	Genera and CLX, but have not yet installed it.  I also don't know
	exactly how to distribute it once it's installed.

	Regardless of that, keep in mind that COPY-AREA (that's what I call it)
	is a pure device-oriented operation.  It does not move output records or
	presentations, it just moves raw bits.  If you want presentations to
	move, you will have to move them yourself.

	I know I have hacks that can benefit from even this very restricted
	operation, but I don't know if it is enough for anyone else?  Comments
	on this, anyone?

    I very often use tools that allow the user to slide/pan etc. a
    presentation by (a) erasing the presentation (b) outputting the
    presentation onto a raster which (c) tracks the mouse until the mouse is
    released and (d) the presentation is represented in the new location and
    state.

    This technique I find robust and very easy to program and use.

This is exactly the facility that DRAGGING-OUTPUT is intended to
provide, except that it presently uses REPLAY instead of "bitblt" to do
the feedback during dragging.  DRAGGING-OUTPUT could be changed to use
"bitblt", except that since "bitblt" can paint only rectangular regions,
the dragging of non-rectangular objects could damage some things that
should not be damaged.

    Anything that provides a vehicle to machine independence of this type of
    operation would be very valuable.

    An extra level of control required is clear control of the "plane" in
    which the movements are contrained - ie. pane, frame, screen, ... whilst
    being allowed to step into viewport scrolling etc. as required.

    BTW, when trying to move the raster about the screen, I constantly loose
    when trying to use #+symbolics graphics:draw-image especially in color,
    so I have always gone for the lowest level bitblting where I can
    understand alus and get performance.

    What general approach should I be adopting in order to take this sort
    functionality into the new dawn of CLIM and portability?

The best approach is to use the highest level of abstraction that CLIM
provides, and don't go any lower unless performance requires doing so.
In this case, that means use DRAGGING-OUTPUT unless it is demonstrably
too slow.  When I get time to finish the "pixmaps" stuff, DRAGGING-OUTPUT
should work properly using it.

0,,
References:
Main Index | Thread Index