Fabio Alemagna <[EMAIL PROTECTED]> wrote:
> > > Which is what I'm saying: let do it to the kgi target, not to the
> > > application.
> > That has been the intention the entire time. Nobody expected users to
> > handle these signals themselves. No target (no matter how superior :)
> > should require ggi applications to insert code specifically for
> > them--that goes against the whole design of ggi.
> This is what Andreas wrote in of of its emails
>> Why make a big deal of it, if the app can just do that:
>>
>> if (have_vtswitch_request()) {
>> backstore=ggiOpen("memory",...)
>> ggiSetMode(backstore,...);
>> ggiCrossBlit(currvis => backstore,...);
>> savedvis=currvis;
>> currvis=backstore;
>> }
> he said the app should do that, not the kgi target, and he said it many
> other times during the discussion.
Yes. And I mean it. The target should reformat the specifics of a
"loose visibility" event from the target dependent format and send it
to the application in a target independent way. E.g. by send an event.
My snippet may have been misleading by using terms like
"have_vtswitch_request()".
However what I mean is:
1. _If_ the application should be able to act upon loosing/regaining
visibility, we should tell it.
The only other way to handle the situation would be that the application
requests what it wants to do in that case beforehand. That is less
flexible, as we would only be able to provide a limited set of
possibilities.
If we tell the app, it can decide what it wants to do. It can sleep,
run on without drawing, run on drawing onta a backbuffer, sleep for
10 seconds, beep and repeat that until switchback, ... whatever
2. If we already do so, I see no point in doing a lot of target-specific
strange workarounds (like fiddling with mmap) just to be able to provide
backing store transparently.
The point is, that _if_ we start guaranteeing it, we _must_ guarantee
it for every future target. Even if it is virtually impossible or takes
a hard performance hit from it.
3. We must cope nicely with the situation that the application is broken,
i.e. it does not handle the request. depending on the target we might
be able to transparently let it run on, for others we might not.
IMHO we should then try a "best effort" approach to handle it gracefully.
Putting the app to sleep if it tries to access something which is
not currently available seems to be the best thing that is decently
easy to implement here.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
