[haiku-appserver] Re: Overlay support

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 22 Apr 2006 19:06:44 +0200 CEST

Axel,

> That was actually a joke, but... well, at least it's pretty usable 
> indeed :-)
OK, I am taking your word for this, since I dont' run Haiku that 
regular yet: though it seems rather stable now :)
And, lots of apps (start to) work..
Well, bitmap output in VLC doesn't work: just a black rectangle is 
shown (it used to work though). Rings a bell? :)

> AFAICT it's a very different mechanism. Acquiring an engine should 
> actually block when it's currently in use, while reserving an overlay 
> channel will just fail - and that's the very purpose of it.

I meant: uint32 ACCELERANT_ENGINE_COUNT(void)
Apart from that you're right. This is because the 2D engine can be 
shared, but an overlay engine can't: it's _always_ working for a 
'client' or output is distorted. 2D engine just executes 'one time 
only' commands and then it's just done.

Anyhow, I guess there's a reason Be set this up as it is. Though it was 
only beta of course. (so) it wasn't fully implemented.
On R5 and dano this hook isn't called either.

I do want to urge you to take Be's implementation seriously though! 
Don't deviate too quick, without properly understanding the whole 
concept of what Be did/tried to do. I guess there might be errors or 
incomplete items though. And Thomas and I might have missed things: For 
completeness: I figured out how to setup overlay (cost me some months 
once), and Thomas implemented it later on in his driver using 'my' 
info. (Of course), he looked further and corrected me on afew things, 
and he looked at the messages and pointers. (and closed drivers were 
checked for behaviour, disassembled a bit)

> Ah, that's very nice! That relieves the memory management in the 
> driver 
> quite a bit.
The driver can never manage it without apps and other clients being 
informed somehow. I actually like the setup be has done. 

> But even if those messages exist, there is no sign of a proper 
> locking 
> scheme when this is done - which would need to be very similar than 
> the 
> direct window mechanism.
You answered this question yourself in the next mail. And Thomas did 
before you. We had long talks in the past.. ;-)

> Theoretically, the app would need to acknowledge to the app_server 
> that 
> it stopped filling the overlay buffer. I also don't think that the 
> BBitmap base pointer will be updated in that case, which would be 
> just 
> broken. I'll investigate into this a bit.
So, the app doesn't inform the app_server, apart from the fact that the 
app uses the overlay hooks via the API and app_server.

The app should respect the app_server, the app_Server informs the app. 
Using those messages. According to Thomas:
-When a modeswitch is initiated, the app_Server sends a stop-cmd 
message to the app. The app gets a fewseconds max(?) before the 
app_Server continues.
-the app needs to stop filling buffers , if it doesn't do so, the 
app_server will kill them anyway by calling the appropriate driver 
hooks (release buffers, release engine).
-modeswitch is done
-app_server requests hooks again. A driver may not export this time... 
(that's the only logical reason for re-requesting, combined with the 
(theoretical) fact that the driver might export other routines because 
of changed hardware constraints in the new mode. Example: VIA driver 
can't do overlay in higher res modes because the RAM is _too slow_ (!))
-app_server sends start-message to the app. app can continue output. It 
may never copy buffer pointers, so it automatically 'sees' the updated 
vallues. That, or it must re-sync buffer pointers after the start-
message comes around.
(I guess the app first needs to check it's 'original' pointers for 
being NULL: if that's the case bitmap mode should be setup)

app must be prepared to fallback to bitmap mode: it's never quaranteed 
that the driver has room for overlay.

The Lockbits() function exists as you saw. Thomas told me this has to 
be the one, though he didn't know if it was used or if it would work.

If you want better details than what I just told you, you can best 
contact Thomas, combined with monitoring what happens with the buffers 
and release/aquire engine yourself. Just enable full logging in my 
driver, start overlay, and Use the screenprefs to change the mode. Look 
carefully at the messages in the log, and compare that too what the app 
itself is responsible for. You can't miss but find that the app_Server 
plays an important 'mediator' role.

Would be cool if Haiku will have a fool-proof solution for this stuff. 
Good luck, it's not an easy item: setting up overlay support ;-)

> > Although no mediaplayer ever yet actually implemented this, and 
> > this 
> > is 
> > (also) the reason Be's mediaplayer tends to crash on modeswitches 
> > (sometimes).
> I don't understand this, though. The overlay buffer is located on the 
> graphics card - it's part of the mapped frame buffer. Therefore, it 
> doesn't go away on a mode change, just the relative position to the 
> start of that buffer may change.

Hmm, true. Well, maybe you should just try it and find the reason then. 
Try this:
-setup Be's mediaplayerto playback a video using ovelray.
-leave it running. Switch modes. (try screenprefs, and try switching 
workspaces with different settings in res and depth)
- You'll definately see it segfaulting... May take a number of switches 
though!

> > > They will also keep there overlay channel as long as they want. 
> > > The 
> > > only hook that would make sense to ask again for is 
> > > B_CONFIGURE_OVERLAY and B_GET_OVERLAY_CONSTRAINTS.
> > > The other hooks just must stay the same 
> > The overlay channel is also released and -re-aquired on 
> > modeswithces. 
> > IT really must be done, since the memory map inside the drivers can 
> > change drastically because of modeswitches: buffers will almost 
> > certainly NOT be recreated at the same locations.
> 
> Sure, but that would just be a requirement of the driver's memory 
> management - which could certainly be solved. 
No, the amount of RAM is fixed. Being able to set a mode has higher 
prioritly that being able to do overlay in a mode. Hence, mode set, 
maybe no ram left for overlay: hence can't allocate 3 buffers (maybe 
just 1, or maybe just very low-res video). Other reason: don't export 
ovelray hooks because hardware has other contraints preventing ovelray 
use (RAM bandwidth too low)

BTW did I mention VIA has actually more than one overlay engine? I just 
didn't set the other(s) up yet...

>Of course, it would be 
> much easier to go the other way around.
Don't say these things, I won't be able to sleep at night! ;-)


> If the overlay channel is released on mode switch there might be a 
> race 
> condition that another overlay bitmap could be created that steals 
> it.
Maybe a shortcoming in Be's setup. Who knows indeed. 


> The real problem of B_OVERLAY_COUNT is that it has this display_mode 
> argument - as if the app_server could do anything about it when the 
> new 
> mode supports a different number of overlays - it would need to 
> trigger 
> the client to renegotiate its overlay bitmaps (ie. recreate them).

Hmm, difficult, that one. Anyhow. The app_server does this itself! app 
doesn't resetup the bitmaps, it just gets updated pointers.
It's confirmed BTW via another way: a long time ago VLC copied the 
references and used the copies. Would work nicely, until a modeswitch 
happened: suddenly the buffers were 'out of sync' (say you had buffer 
1,2 and 3, suddendly the order was 2,1,3 or other options. Solution: 
don't copy refs, just use the original. Problem solved.

Bye!

Rudolf.


Other related posts: