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