From: Jason McMullan <jmcc@ontv.com>
  To  : ggi-develop@eskimo.com
  Date: 15 Jul 1998 13:57:28 GMT

Re: Palette restoring...

Marcus Sundberg <e94_msu@e.kth.se> wrote with confidence:
> This is currently a somewhat confusing, to say the least,
> issue...

> In the libggi-issues document we have:
> Pending, paragraph 1.3:
>   It is still unclear whether restoring the palette is done by the application
>   (along the redraw action), or by the libggi (target).
>   Most targets have a local copy of the palette anyway, so it would be rather easy.

	On redraw, libGGI will take care of the palette. This is part of
the graphics state (libGGI), not part of the drawn visual (app).

> Resolved, paragraph 2.11:
>   The palette setting is not necessarily kept on a focus switch, so when an
>   application needs to redraw the screen, it has to re-set the palette as well.

	Hmm... libGGI should handle that. (Andy?)

> Resolved, paragraph 2.14;
>   It seems to me that the application is guaranteed that all graphics state is
>   saved and restored transparently (including the CLUT) except for the screen
>   content itself, where the application is supposed to redraw after receiving
>   an appropriate redraw event.

	Correct. 

> Somewhat contradictory huh? ;)
> I certainly vote for the last one!
> The only target where this is relevant is the KGI-target, and
> IMO it's better to add this functionality to one target than
> hundreds of applications.

> But actually this functionality belong in the driver and not
> in libggi at all. Any 256 color CLUT will fit very well into
> 2k, and the other gfx states shouldn't use that much either.
> And I don't consider 1 page of kernel-memory per fullscreen
> app anything to fuzz about at all...

	We have to do it for text modes anyway (including
`graphical' text modes), so why not...


-- 
Jason McMullan - Linux - GGI - http://pepsi.visus.com/~jmcc

On the wonderful world of Microsoft Products:

  Why put fault tolerance in the OS, when it's 
  already built into the User?
	-- Steve Shaw <nospamola_sbshaws@kc-primary.net>
	   comp.os.linux.advocacy