[vdr] cBitmap::Dirty isn't working

[Reinhard Nissl]

Hi,

Luca Olivetti wrote:

> Well, /me doesn't understand :-(
> After forcing the femon plugin to use 3 areas (with xine it would use 
> just one covering the entire screen), I can see that if I use xine I get 
> the correct values in Dirty (21 for "Transponder information", 17 for 
> "Stream information" and 21 right before clearing the title) while with 
> the dxr3 I don't (get the last 21).
> Since both xine osd and dxr3 osd take the drawing methods straight from 
> cOsd[*] I'm really lost seeing the different results.
> 
> [*] I saw that you redefined them then called the base one like, e.g.:
> 
>   eOsdError cXineOsd::SetAreas(const tArea *Areas, int NumAreas)
>   {
>     cMutexLock osdLock(&m_osdMutex);
>     return cOsd::SetAreas(Areas, NumAreas);
>   }
> 
> I tried doing the same to see if using the mutex made the difference but 
> it didn't.

This mutex is just used to prevent vdr-xine from transfering a bitmap to 
xine which is currently processed by VDR. Transfering the bitmap 
asynchronously (e. g. due to xine reporting a change in stream 
resolution) to xine resets the dirty area and when VDR finally issues 
the Flush(), the dirty area of that bitmap might be incorrect, resulting 
in garbage on OSD.

But it's not that perfect. The mutex doesn't protect anything when VDR 
or any plugin access the OSD's bitmaps directly. A more correct approach 
would be to synchronize just the Flush() and to copy all bitmaps there. 
When xine requests the OSD to be sent asynchronously, just the copy gets 
sent which remains stable until it get's updated by the next Flush().

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de