FreeLists / haiku-appserver / [haiku-appserver] Re: Overlay support

["Rudolf" <drivers.be-hold@xxxxxxxxxxxx>]

Hi there Jonathan,

As Axel pointed out later, I am just trying to describe how things are.
However, I have some remarks.

> ... and quite possibly allowing the user to lose data, or at least 
> sanity, for doing something they thought they could do without harm, 
such as changing to a different workspace temporarily, or changing the 
resolution of the current workspace, or whatever it is that caused the 
snafu that's limited by reality. 

There's no change that data gets lost: we are talking about the app 
playing back video only. The system remains totally stable.True, 
sometimes a user sees a behaviour that he or she didn't anticipate, and 
certainly doesn't understand. However, It's not always possible to 
prevent such a thing from happening. Although we (BeOS/Haiku) should/
will certainly do our best to minimize this kind of thing. Personally I 
hate that too. Users should be able to use a system without having in-
depth technical knowledge :)

> 2.  The user decides to change to a different workspace or resolution 
> in the workspace(s) that use the overlay, but for whatever reason, the 
hardware can't accommodate that switch, or requires renegotiating 
everything.  From what I've read, it seems that if there isn't a 
response within a given amount of time, that the application using the 
overlay is killed, either by choice or by default due to things being 
changed out from under it.  Well, frankly, this shouldn't be remotely 
time-based, at least, not without user intervention.

It isn't time based. There's a 'system' that handles this without the 
user interventing or experiencing problems, and it even doesn't crash 
the app if it's written correctly (and it will be ;-)
The time-based thing is just the backup system that will crash the app 
if the app potentially would bring trouble to the system and user. So, 
it's the app causing your concern here, not the system.

> Quite possibly the system is very busy, and the application can't 
> process a message ASAP, which may be directly related to the fact that 
it needed the overlay in the first place.  What should have the highest 
priority? 

Priority. I used that word here:
-highest priortity is that the system should be able to set the mode 
the user requested (implicitly or explicitly).
-below that priority lie all kind of options in theory available in a 
given mode, like 3D acceleration and video overlay. Later on offscreen 
desktop composition will also be such a option.

I perfectly understand that this stuff might be not that obvious to a 
lot of users, and that's why the system should automatically come up 
with replacements for these options should they not be avaiable 
'suddendly'.
-In case of video overlay the app should fallback to bitmap mode;
-In case of 3D the 3D function library should automatically start to 
flip textures on the fly, or even fallback to software rendering mode;
-In case of offscreen composition the system should fall back to the 
(now default and only) onscreen composition.

In all cases, the only thing the user will witness, is a slowing down 
of components. No crash, no lacking functionality, no data loss. It 
just works, and it keeps working. It even looks 'exactly' the same.
However, from the technical viewpoint these things require re-
negotiation of the actual method used. This is a totally 'under the 
hood' thing, and there it should be.

So, as far as I'm concerned one item remains:
-why do I call setting a mode top priority, and all other stuff 
'options'?. 
Well, they are options because without the mode working, they can't be 
done. As simple as that. You wouldn't have a picture at all... (OK, I 
might be oversimplifying a bit, I admit ;-)

-why is it required to resetup a thing like overlay, even though in 
most modes it would work? The reason is rather simple as well: a new 
mode requires more (or less) memory. If the overlay data lies in a part 
of memory now required by a mode, then it must be relocated. A mode 
requires one block of memory, no chuncks allowed. This is all dictated 
by hardware, and can't be overcome mostly.

> 4.  Depending on whether it is an old application or not, it responds 
> by either calling the new API function release_overlay() in a timely 
manner, or the app_server asks the user (or consults preferences and 
finds the one for overlays) and acts accordingly, either ripping the 
rug out from under the application, or failing the attempted mode 
switch that would cause the application from losing the overlay.
Well, in a sence a segfault is a message to the user telling him or her 
the app doesn't work correctly. If it would be a video-mixing app, then 
you'd loose your data forthis app if it didn't do intermediate saves. I 
can see how it would be handy in such a case if a user would be given 
the option to not issue the modeswitch here, instead of crashing the 
app. In a perfect world that is, personally I've never seen this kind 
of behaviour on _any_ OS yet. I'd be very satisfied already, if we have 
in place what I described, and segfaults, if they happen, are at least 
consistent (same relative time and place, so they can be easily tracked 
back). In the R5 days, this was already reasonably well there, 
certainly if compared to Windows 9x... ;-)

Hope this info settles things a bit for you.

Best regards,

Rudolf.