At lest so it seems here, but I cannot find where the fault is. The dxr3 osd uses this method to only copy in the osd buffer the changed portions of the bitmap, but I'm seeing problems here that disappear if I copy the entire bitmap. It's easy to test with the femon plugin: toggling between the various display modes, when the signal information disappears it leaves a line under the title. The femon plugin uses 3 cBitmaps, number 1 for the signal strength, number 2 for the title of the signal info and number 3 for the signal info. Bitmap 2 is 22 pixels high. In the Flush method of the dxr3 osd, I put a diagnostic printf to see what Dirty is returning. When I switch the signal info on ("Transponder information"), Dirty correctly[*] gives 21. Switch to "Stream Information" and it correctly gives 17[*] (no character below the baseline, I suppose that the first time it gives 22 since the title is correctly refreshed, no remnants of the "p"). However on the next toggle (bitmap 2 and 3 are set to transparent) Dirty still gives 17 instead of 21 (I'd expect a 21 since all pixels have changed to transparent). [*] note that it gives me a 17 each Flush, maybe it's not correct: since the bitmap hasn't actually changed it shouldn't be really Dirty.
Note that femon is just an example, I see similar problems with other plugins (e.g. text2skin). Since the method used by the dxr3 plugin in Flush is the same as in dvbosd (minus the copying of the bitmap to the display of course), I wonder if ff users are seeing the same thing and where the problem actually lies. I've also noticed that the xine plugin doesn't bother to copy only the changed areas, it copies the whole bitmaps in each Flush, I didn't check softdevice.
Bye
Hi,
Luca Olivetti wrote:
I've also noticed that the xine plugin doesn't bother to copy only the changed areas, it copies the whole bitmaps in each Flush, I didn't check softdevice.
Which version of vdr-xine did you check? vdr-xine uses the dirty area for quite a long time. In 0.7.3 I've added to check whether the dirty area really differs from the previous call as VDR's channel display was said to be dirty in each flush, and this resulting in high CPU load on less powerful machines like the EPIA MII-6000E which only has a 600 MHz CPU. vdr-xine now only sends the dirty area to xine, if the area really differs from the last flush.
Bye.
Reinhard Nissl wrote:
Hi,
Luca Olivetti wrote:
I've also noticed that the xine plugin doesn't bother to copy only the changed areas, it copies the whole bitmaps in each Flush, I didn't check softdevice.
Which version of vdr-xine did you check?
0.7.2
vdr-xine uses the dirty area for quite a long time.
You're (obviusly ;-) right, I misinterpreted the unconditional call to SendWindow as a full bitmap copy, while the check for Dirty is made inside SendWindow. I'll have to investigate more where the problem comes from.
Bye
Luca Olivetti wrote:
Reinhard Nissl wrote:
Hi,
Luca Olivetti wrote:
I've also noticed that the xine plugin doesn't bother to copy only the changed areas, it copies the whole bitmaps in each Flush, I didn't check softdevice.
Which version of vdr-xine did you check?
0.7.2
vdr-xine uses the dirty area for quite a long time.
You're (obviusly ;-) right, I misinterpreted the unconditional call to SendWindow as a full bitmap copy, while the check for Dirty is made inside SendWindow. I'll have to investigate more where the problem comes from.
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.
Bye
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.
-
Luca Olivetti -
Reinhard Nissl