[MPlayer-dev-eng] Removal of backing store

[Stephane Marchesin]

On Sun, Aug 24, 2008 at 10:27 PM, Vladimir Mosgalin
<mosgalin at vm10124.spb.edu> wrote:
> Hi Stephane Marchesin!
>
>  On 2008.08.24 at 18:50:45 +0200, Stephane Marchesin wrote next:
>
>> Because if the window is made transparent for example, you can't use a
>> real hw overlay. And the driver has no way to know which is the
>> current situation, since this is the compositing manager's business.
>
> You are talking about old cards, right (since newer ones don't have hw
> overlay)? And most likely they're used in older systems. I doubt that
> you'll be happy when your video playback suddenly slows down a lot when
> you start moving window over desktop or setting its transparency. And if
> it doesn't matter for you, just use textured video in any case..
>
> Honestly, I'd prefer system which doesn't magically switch video
> rendering backends behind my back, but always provides adequate level of
> performance.

Well at least you don't get bugs. I'm not interested in bugs that go
"overlay becomes blue when the window is made transparent" or "mplayer
window becomes blue when it is made transparent, that doesn't happen
with xine or vlc". What I'm proposing is, as far as I know, the only
way to get a bug-free default behaviour with the best possible
performance in each situation.

>
>> Read what I said, the hw overlay's not default, so you get slow speed
>> for everyone as default. People who want to use the hw overlay anyway
>> will get blue screens in some situations.
>
> I understand your logic, but IMHO it's too far from real life. The
> speed penalty for using textured video in non-composed environment
> should be pretty small. And if it isn't, it means that you have really
> old card or you're playing high res video, in which case textured video
> in composed environment is absolutely no-go - it'll be slow as hell.
>
> In my case, even 640x272x25 video (window output, no scaling) becomes
> unwatchable with textured video when compiz is running. If some effects
> are over it, it's almost slideshow. However I can play 720p video (with
> -vf-clr option and 95% cpu load) on the same system through hw overlay,
> with or without compiz and through textured video when compiz isn't
> running.

Right, that's exactly my point. ATM what's preventing other drivers
from doing the same fallback trick is that they fear "blue mplayer
window" bug reports.

And having an adapter which fallbacks doesn't prevent you from having
an overlay-only adapter if you really want. Or you could just ask the
window manager to always underirect the window which has the same
effect.

>
>> So you say people should be able to understand what happens with
>> window redirections and Xv ? Considering you don't seem to understand
>> it fully, do you expect others to ?
>
> No, but they'll ask on forums or something. After all, the target
> auditory isn't that big (people with older cards using compiz).
>
> Also this is pretty minor issue comparing to what happens to other
> opengl applications under compiz, I must say.. (we're all eagerly
> waiting for DRI2).
>

Sure, there are other bugs. But why can't we fix the ones we've
understood and diagnosed ? By that reasoning, we shouldn't fix any
bugs :)

>> Yes, and we can have a "best effort" choice, one with an adapter that
>> automatically switches from hw overlay to blitter when the window is
>> being redirected. This means, inside a compositing manager, that you
>> get :
>> - when the window is opaque and untransformed (that's called
>> "unredirection"), the hw overlay
>> - otherwise, the blitter/textured adapter
>> This is an optimal situation, I don't understand why you criticize it
>> ? Please enlighten me.
>
> (read before)
>
> Anyway this is getting quite OT. My original point was that hw overlay
> vs. textured video and direct output vs. redirected shouldn't have
> anything to do with backing store, and behavior of intel drivers proves
> it, as I see it.
>
> What I prefer and what do you prefer are different things, if you like
> that "best effort" choice that you describe then it's fine (though I
> certainly hope it can be turned off, because I think it's useless). But
> if something like backing store can hurt it, it's driver bug. This fact
> doesn't have anything to do with our preference ;)

My idea will not force anyone to drop the old-fashined overlay.
Instead, it'll make the default behaviour bug-free. If you want to
play around with stuff, fine.

>
> Btw even if you say it's the same, I find them quite different - some
> effects in compiz are really slow on 915, and some complex ones aren't
> available - but they work on 945 and pretty fast, too. I'm pretty sure
> about that because I use 915 system with compiz every day.
>

I'm not making this up, the intel guys themselves say so. The
performance sure differs between i945 and i915, but not the features.
What you have is a software problem most likely (outdated drivers ?).
Look at the mesa i915 DRI driver for example, it handles the i945 as
well with the same code. Try grepping for i945 in there, and see that
the only different codepath is for texture mpitree storage. Out of a
whole 3D driver, only the texture storage differs. This is 200 lines
out of 16000.

Stephane