[haiku-appserver] Re: Overlay support

Perhaps we aren't visualizing the same reality here: do you mean you consider 
it perfectly acceptable to kill an application that doesn't jump when you say 
"Jump right NOW!" when it is very busy, because the system is so loaded down 
that it is swapping heavily, for instance?  The application could be working 
perfectly correctly, and doing things as timely as reality could ever permit 
given the resources, but it simply can't respond *that* quickly, due to 
hardware limitations it can't control.

My point is that other than the system quite possibly being very limited in 
hardware resources available due to load, is that the user should ultimately 
have control over what dies and why and when, and the principle of "least 
surprises" is kept when they do something, like switch modes.  When may work 
for switching resolutions/color depth on one machine suddenly doesn't work on 
another computer, or even on the same one, depending on conditions, that can be 
surprising: when they lose something (such as data, if they were recording 
something live while watching it, for example: think TiVo/DVR) that's not only 
surprising, but data loss that will cause even the most reasonable users to get 
rather upset.  I argue that my proposal for protocol is both backwards and 
forwards looking towards the users and developers of applications: it allows 
for reality beyond the control of the developer to be adapted to in a way 
explicitly controlled by the user, whom is ultimately the one that should have 
the power over policy on *their* machine.  If they want to terminate an 
application, that's what the three-fingered-salute and Twitcher is all about, 
which should always be available at a higher priority than other things.  After 
all, it just may be that the user did something by accident that they never 
anticipated would cause what would be (to them) very contrary to their goals of 
computer usage.  From what I read in the Be Book as documented about the two 
overlay messages, those are notifications from the graphics driver that are 
confirmation messages, more than messages saying "Do this now or die in n 
seconds, you losers!" and if anything could be argued, that the 
B_SCREEN_CHANGED message should be handled and taken into account by the 
application, and that *may* affect the overlay, but then again, depending on 
the hardware, it may not.

Since this is a list dedicated to the development and refinement of the Haiku 
app_server, which should remain sufficiently (not perfectly, just where it 
makes sense!) backwards compatible with BeOS 5.03 while also looking towards 
the future: this is one of many areas [overlay support] where it appears Be 
punted in both documentation and coming up with a fully-thought-out solution, 
so I'm proposing something that favors the principles of this being a desktop 
OS where the user is in control and the principle of least surprise.  I say 
let's define that protocol with those goals in mind for future use, and let's 
very clearly and explicitly document whatever is decided as "The Correct Way" 
because the old BeOS documentation leaves a lot to be desired, like (in too 
many cases) major details such as the fact that a user space application can 
allocate lots of memory in the kernel address range (to be more explicit, < 1 
GB address range and up) via create_area using B_EXACT_ADDRESS :) (I threw that 
in out of curiosity if the Haiku kernel would satisfy any possible 
B_EXACT_ADDRESS create_area that isn't already taken: based on my tests, this 
is what will make it possible for Bryan and Andrew to complete a 5.03 and Haiku 
compatible Java VM port).

>jonathanthompson@xxxxxxxxxxxxxxxxxxxxxxx wrote:
>> The earlier discussions of a time value being used and causing things 
>> to
>> fail just strikes me as sick and wrong, if things aren't available.
>
>Rudolf just described what's there right now in R5.
>If an application doesn't adhere to a certain (and in the future, well 
>documented) protocol, I certainly don't have a problem with letting it 
>crash. It deserves no better :-)
>
>It's like the direct connected timeout: if an app needs more than (on 
>R5) 3 seconds to acknowledge a change, it will get killed. The 
>app_server can't do a lot before that point, it just have to wait until 
>the shared resource become available for it again.
>And with high performance video stuff like overlays and direct windows, 
>a response timeout from 3 seconds or even 1 second doesn't sound like 
>too little to me. Such timeouts can easily be met within an application 
>so I don't see much value in having that additional user interaction.
>These kind of errors should be fixed during application development.
>
>Bye,
>   Axel.
>
>

Other related posts: