Hi, (sorry for the delay BTW) > My AppDefs.h (from Dano, dunno about R5) defines the following > messages: > B_ACQUIRE_OVERLAY_LOCK > B_RELEASE_OVERLAY_LOCK 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: 1. 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 nessesary. 2. 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... 3. 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 :) Bye! Rudolf.