From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Wed, 28 Jul 1999 11:45:02 +0200

Re: Concepts for the Term : Visual

> 	The concepts on Visual described in the Manual
> 	is "Simply something you can draw on".
> 
> 	After reading the declaration of the ggi_visual_t
> 	in internal/structs.h , it seems to be some kind 
> 	of "device context" specifying the gamma , frame
> 	buffer currently used , colormap ...etc.

Yes. The reasons for binding the two are, that for the stuff you mentioned,
there usually exists a 1:1 relation for a given device and for the "drawing
context", which is also bound to the visual, we did it, because most hardware 
has only one drawing context, which lead us to bind it to the visual, as
this encourages a programming style that tries to avoid context swaps.

> 	The mentioned "it can be an X-Window" is done
> 	by using multiple visuals representing multiple
> 	windows....

Yes. Each X window is a visual of its own right.

> 	The main functions of visual is still a full screen
> 	buffer ... Am I right ??

Basically. It's just as stated in the docs. A visual is something you can
draw on. No matter how it is displayed. It may be in a window, on a second
screen, printed out, whatever.

> 	It's also mentioned that the visual can be a memory
> 	space , 

Yes. You just open a "memory" visual for this.

> can we dynamically move the memory frame??

What exectly do you mean ? When creating the memory visual, you can tell it
to either malloc the required memory, or to use preallocated memory or
to use shared memory.

It is as of now not possible to change the memory pointed to by the visual
internal structs actively after the visual is created.

However such functionality could be implemented by using an extension. 

Could you detail your possible application, so that I can see a little more
clearly what you want to achieve ?

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =