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
--
- Yo tambi?n quiero una Europa libre de Patentes de Software -
- I want a Software Patents Free Europe too! And you? -
---------------------------------------------------------------
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050418/7390da4f/signature-0001.pgp
