delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/03/03/12:37:36

Message-ID: <D1FB30BBA491D1118E6D006097BCAE39111621@Probe-nt-2a.Probe.co.uk>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Allegro -- any interest in a Win95 look-alike GUI
Date: Tue, 3 Mar 1998 17:34:50 -0000
MIME-Version: 1.0

Doug Eleveld writes:
> Another thing that I am stuck on is how to keep overlapping windows 
> from writing over each other without keeping a big bitmp for each 
> internal window.  The background and 2 or 3 big opened overlapping 
> windows on a 1024x768x24 screen (something that I regularily do in 
> Windows) is going to be a huge chunk of memory.  There just has to 
> be a smart way of that without the waste of space or time.

In Windows that is all taken care of by the GDI graphics drawing
routines, which can clip to any arbitrary region. The device context
for drawing the window contents is produced from a number of 
rectangles depending which parts of the image are visible, and
things are automatically only drawn within that region. This makes
things easy for the application programmer, but obviously isn't very 
efficient, and it would be hard to implement in a way that would be 
portable across different graphics libs.

On the Atari, the GEM windowing system didn't try to enforce drawing
within the window limits, but left it up to the application program.
It would provide a list of rectangles that were safe to draw into,
so typically an application redraw looked something like:

    rect = GetFirstDrawableWindowRectangle(wnd);
    while (rect != empty) {
        SetClip(rect);
        DrawWindowContents();
        rect = GetNextDrawableWindowRectangle(wnd);
    }

At first sight this looks very clunky, but it is quite simple from
the perspective both of the window manager and the application 
program, and can work quite well because in most cases there will 
only be one active rectangle. If parts of a window are obscured
by many others it can become grossly inefficient, which might be
a problem if you have many floating toolbar type objects, but it 
is great in an environment like GEM where you are usually working
(and hence causing redraws) in the topmost window...

    Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019