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