Lisp HUG Maillist Archive

Double-buffering, scrolling and clipping

Hi List,

On WinXP I double-buffer my main application pane with a backing pixmap. I also
have a power-of-two zoom facility, and my assumption has been that in order to
maintain buffering whilst scrolling I have to create a pixmap as large as the
scroll-width of my displayed pane. Obviously with power-of-two zooming the
off-screen buffer quickly becomes VERY big.

Possibly the above is a naive approach, and I'm now searching for an
alternative. It seems wasteful, especially since all my drawing is clipped -
surely I should be clipping my pixmap as well. Two (related) ideas I have in
mind are:

1. Draw directly to the pane, but cache a backing pixmap which is only as
   big as the viewport. At the end of a paint event copy all pixels from the
   pane to the pixmap, and then just copy back from the pixmap to any damaged
   regions later. A new pixmap should be generated on any resize or zoom event.

2. Generate a pixmap with each paint event, and cache it. On scrolling
   simply copy the relevant section from the cached pixmap to the new one,
   but shift it by the width of the newly exposed region (which is drawn
   directly to the pixmap). I suspect this is how a lot of applications manage
   it, though I haven't found much to go on. I suspect it might not be so
   efficient in the CAPI, though.

The following Qt-related post suggests something like option 2:

http://labs.trolltech.com/blogs/2009/02/06/improvements-to-qgraphicsitemcachemodes-insides/

I would be very interested in any thoughts on this (thorny) topic!

Many thanks,
Chris 


Re: Double-buffering, scrolling and clipping

On Tue, 20 Jul 2010 19:06:47 +0100, Christopher Melen  
<relativeflux@hotmail.co.uk> wrote:

> On WinXP I double-buffer my main application pane with a backing pixmap.  
> I also
> have a power-of-two zoom facility, and my assumption has been that in  
> order to
> maintain buffering whilst scrolling I have to create a pixmap as large  
> as the
> scroll-width of my displayed pane. Obviously with power-of-two zooming  
> the
> off-screen buffer quickly becomes VERY big.

It is hard to give any feedback without seeing what your interface looks  
like.


Re: Double-buffering, scrolling and clipping

Unable to parse email body. Email id is 10406

Re: Double-buffering, scrolling and clipping

Why don't you draw directly to the pixmap ? Subtract the scroll-x and
scroll-y to your coordinates when drawing. You can do this with this macro

(gp:with-graphics-translation (view-port (- scroll-x) (- scroll-x))
    ... Your draw codes here ....
    )

Then copy the pixmap (or a part of it) to the view-port at the end of the
display-callback.

Like this you can zoom at any level you want, the process stays the same.

Best regards

Denis


Le 20/07/10 20:06, « [NOM] » <[ADRESSE]> a écrit :

> 1. Draw directly to the pane, but cache a backing pixmap which is only as
>    big as the viewport. At the end of a paint event copy all pixels from the
>    pane to the pixmap, and then just copy back from the pixmap to any damaged
>    regions later. A new pixmap should be generated on any resize or zoom
> event.

-------------------------------------------------------
Denis Pousseur
70 rue de Wansijn
1180 Bruxelles, Belgique

Tel : 32 (0)2 219 31 09
Mail :  denis.pousseur@gmail.com
-------------------------------------------------------



RE: Double-buffering, scrolling and clipping



> From: chyde@cox.net
> To: ndl@ravenbrook.com
> Subject: Re: Double-buffering, scrolling and clipping
> Date: Tue, 20 Jul 2010 15:11:52 -0400
> CC: relativeflux@hotmail.co.uk; lisp-hug@lispworks.com
>
>
> Think about how google maps does it's zooming...
>

No idea... seems like they use a buffer a bit larger than the viewport, though. You can see the updating regions if you pan fast enough.

Chris


Get a new e-mail account with Hotmail - Free. Sign-up now.
Updated at: 2020-12-10 08:39 UTC