Re: Tools

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> > This one is hard to get right with some targets, particularly the
> > console ones. For example, on a VC switch, you have to give up the
> > content of your video memory, on and offscreen. I guess moving the data
> > in video memory to system memory before doing the VC switch is the right
> 
> This was discussed on the GGI list some time ago - and it's problematic.
> New cards come with 32MB memory, and you can relatively easily get one with
> 64M. 128M cards are available. So "swapping out" the video mem can be
> really hard on the system.

Yes, that becoming more and more the current state of things. But also
note things like AGP Fast Read and that moving 128 megs over the PCI bus
takes around 1 second, which is about how much time it takes to switch
to an X server anyway. You don't have to save everything, only what
cannot be recreated easily (something like a cached pixmap can be
dumped, but a "hardware pixmap" that lives on the card is different).
But still...

> Saving only basic card state (mode etc) and giving the game a "redraw"
> signal afterwards should be a better solution.

.... I won't save the memory. The API we are designing has some
resemblance with the Xlib API, so something similar to an Expose event
for Drawable could be possible (in real Xlib, they can only happen to
Window, not to Pixmap). Saving the memory could be an option, like the
backing store in X.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi