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@xxxxxx
