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?
Marko
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
