On Samstag 23 September 2006 21:45, Marko Mäkelä wrote: > On Fri, Sep 22, 2006 at 11:12:56PM +0200, Stefan Lucke wrote: > > > One or two weeks ago I have noticed that when something is blanked > > > (made transparent) in the OSD of -vo dfb:mgatv, the change does not > > > happen immediately, but the pixels will fade out in at least 4 steps. > > > > This fading effect is caused by not clearing non-video area (black > > borders). It most visible in paused mode when there are OSD changes > > outside the active video area. > > > > Attached patch dfb-blbar-clear-02.patch should fix this. > > Tested this only in pause mode. As this may cause a higher > > load, it should be tested more careful on small systems. > > This one worked for me. Test case: pressing the Up or Down key for several > seconds in a short Recordings menu (which fits entirely on the screen) > while playing a recording. The CPU consumption grew from about 55% to > 80%, but very few frames were dropped, and the selection on the OSD menu > was updated smoothly. > > > Patch dfb-blbar-clear-03.patch includes this and osdMutex removal > > from video-dfb.c . Did only a compile check with this one. > > I tested this one first. It removed the fading effect, but unfortunately > it also caused OSD updates to take much longer or to be lost. When I > pressed the Down button for a second in a short Recordings menu that fits > entirely on screen, the selection jumped around in a bit chaotic way. > I'm just guessing, but could it be a locking granularity issue?
Was that during live-tv or during a paused playback of a recording? Could be an issue with triplebuffering too. -- Stefan Lucke _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
