[MPlayer-cvslog] r27849 - trunk/libvo/x11_common.c

[Uoti Urpala]

On Thu, 2008-10-30 at 19:58 +0100, Reimar Döffinger wrote:
> On Thu, Oct 30, 2008 at 08:35:58PM +0200, Uoti Urpala wrote:
> > Enabling backing store is apparently harmful in xserver 1.5.
> > See http://www.nvnews.net/vbulletin/showthread.php?t=119047 (I already
> > posted that link when it was discussed before).
> > 
> > I didn't see any mention of backing store being useful in the earlier
> > mplayer-dev-eng thread. The above link says it's harmful in some xserver
> > versions. Given that, turning backing store off seems reasonable to me.
> > Even working around buggy drivers would be an OK reason if there's no
> > clearly explained rationale why it would should remain on (switching it
> > off seems unlikely to trigger any new bugs).
> 
> Oh, I do not disagree, but this was never discussed as "workaround for
> X.org 1.5 performance issue".

The main issue discussed in the above link is tearing-like corruption
due to draw redirection without vsync, not performance.

> I'd probably agree that it is worth it, but now even the commit message
> says the reason is it is "useless" which seen even in the most positive
> light only means there is no reason to keep it but is not a reason to
> remove it, which a commit message certainly should contain.
> Thus my question, which is the actual why and why was that reason
> considered more important than the performance improvement that probably
> could be possible with a well-implemented X-server (note this file is called
> x11_common.c, not xorg_specific_x11_common.c)?

What performance improvement? You mean you think MPlayer enabling
backing store could improve performance at least on a theoretical X
server? I don't see how that could be the case; a server is already free
to keep the bitmaps in memory if it thinks that's good for performance,
while forcing that behavior can require extra copies which degrade
performance. The data is only required during expose events which are
the exceptional case, so backing store should not give any benefit
during basic playback while the requirement to always keep the data
ready in case an expose event happens can add overhead.