[haiku-appserver] Re: Overlay support

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 25 Apr 2006 11:24:10 +0200 CEST

Hi, (sorry for the delay BTW)

> My AppDefs.h (from Dano, dunno about R5) defines the following 
> messages:

those are the ones indeed.

> > And you (app) must release the lock as soon as the app_server sends 
> > you 
> > the stop message, or it will make you segfault. (ah, that's why 
> > mediaplayer segfaults.. ;-)
> Well, what an application needs is the following:
> 1) a hint when I must unlock the bits, and another when when I can 
> lock 
> them again. This could also be understood as a hint towards pausing 
> and 
> resuming rendering (ie. in case the video is hidden).
> 2) a notice when my overlay channel got lost (ie. because the new 
> display mode doesn't support overlay anymore).
> While the 2 messages above solve 1), they don't touch 2) at all. I 
> think we have two options to deal with this:
> a) let LockBits() fail - this should be a convincing hint to 
> renegotiate your overlay connection.
> b) let Bits() return NULL
> Since b) would let older correctly written apps crash, I would 
> consider 
> a) the better version. We may also need to come up with a mechanism 
> to 
> let applications survive that don't support the messages above (but 
> calling LockBits()/UnlockBits() frequently).

I agree, I agree. :)

> Ie. if the mode switches, video overlay might be gone for a fraction 
> of 
> a second only - there is probably no point in unlocking the bits 
> between the mode switch

I don't agree. That is, the app may _not_ write data to the bitmaps 
during a modeswitch, since they might be relocated and if you write at 
the old locations you might end up messing up the workspace. At the 
very least, I think it's much neater (cleaner) if an app doesn't write 
data in a gfx memory that's in the process of being reconfigured.

> (but that could be done, of course). OTOH if 
> the workspace changes, and the video is no longer visible, it 
> wouldn't 
> been right to hold the lock for so long.

I have a number of thoughts here:

I think the application should not send data to overlay buffers when 
another workspace is visible: these buffers (could) simply don't exist 
at this time. And it loads the CPU and card while that's not really 

Although, I might be mistaken: maybe the app_server asks for new 
overlay bitmaps anyway, and the app can safely fill them therefore. It 
still serves no purpose though. From observations I (think I) know that 
Be's mediaplayer _indeed_ stops filling ovelray buffers, while all 
other existing (open) apps don't know about this switch and simply keep 
sending buffers. VLC for example _even_ keeps sending buffers when it's 
video is paused. I can't remember seeing corrupted desktops, then again 
I mostly use the same resolution and colorpspace on them all...

Well, if I think about theoretical options inside gfx hardware, I might 
find this approach interesting: 
-the app_server sets up new overlay bitmaps during that other workspace 
visible time, so the app can keep sending those bitmaps. Although it 
won't be shown on this new workspace, the driver might have TVout 
enabled where these bitmaps get sent. I am now describing a Matrox hw 
feature that offers to both send overlay bitmaps 'in a window' on your 
desktop, and simultaeoulsy to the TV set. The TVencoder can colorpspace 
convert from Y_CbCr422 to RGB by itself, so the overlay bitmaps are 
used as a source for _two_ outputs at the same time.

As I just said, this is theory, and I don't know if I would (want to) 
support this. It seems a specific Matrox feature, no 'common' feature. 
We could forgego that option, and keep it plain and simple: seperated 
TVout and desktop in every aspect. In this case the TVencoder could be 
connected to the card's second head, that head could display video in 
bitmap mode, and this would be displayed on TV. The other head uses the 
ovelray engine on a workspace currently not visible. (matrox doesn't 
support overlay on TV mostly).

> If the application supports 
> the two messages this wouldn't be a problem, of course. But if its 
> doesn't (and I guess no existing will), we might need the application 
> another buffer it can play with for the time being. This could be 
> solved entirely client-side, though, with BBitmap allocating such a 
> buffer on the fly.

All in all, I find 1. the cleanest and simplest thing I think. But it 
might be that (the) extra BBitmap(s) needs to be created by the 
app_Server then to keep old apps working after workspace switches, 
since I can imagine on R5 and dano ovelray is setup on that other 
workspace even though it shouldn't be shown there. (I could verify that 
of course)

> I guess proper documentation would have worked, too, though :-)
> But since we're open source, we don't get around providing the 
> reference implementation, anyway.

Loving open source :)



Other related posts: