[MPlayer-cvslog] r18718 - in trunk/libvo: vo_x11.c vo_xmga.c vo_xv.c vo_xvidix.c vo_xvmc.c x11_common.c

The Wanderer inverseparadox at comcast.net
Sat Jun 17 20:37:51 CEST 2006


Reimar Döffinger wrote:

> Hi, On Fri, Jun 16, 2006 at 09:55:46PM -0400, The Wanderer wrote:
> 
>> The same behaviour occurs with x11, gl, and gl2; similar but no

[note: this list is "in addition to xv"]

> [...]
> 
>> I'm not 100% positive this counts as a bug (it's possible that I
>> could, via much experimentation, figure out the correct values to
>> pass to the -geometry option in order to get the window to sit
>> where I want it to), but it is for me undesirable behaviour, so I
>> thought I'd make note of it.
> 
> I know it has some disadvantages, but I think that
> 
> 1) gl and gl2 behaved like that even before the patch, so at least it
> makes things consistent

I don't remember that being the case... at least, back when I used -vo
gl by default, I seem to remember being able to have the window manager
restore initial window position without difficulty. I'll test that when
I get the chance (I'm compiling something else right now).

Looks like you're right - -vo gl with r18717 behaves the same way as -vo
xv does in later revisions. (It didn't do that the first time I tested,
but it has on all subsequent tests; probably I just gave the wrong
command line or something.)

> 2) the old code did not behave so well with -fixed-vo and playing in
> fullscreen multiple files, IIRC if you switched back from fullscreen
> on the second file the window would have size and aspect of the first
> one.

Yes, I remember this from the mailing-list discussion (even if I've not
been able to find said discussion). However, it seems to me that window
size *should* (in theory) be independent of window position... maybe
I'll have a look at the code and try to figure out a way to manage that.

Actually, I'm not 100% sure we're on the same page here. To be
completely explicit: this behaviour happens for me when operating in
purely window-based mode, without -fs on the command line and without
toggling; fullscreen doesn't enter into it on the user side.

Looking at the code, I'm not sure why it's different, since this change
seems like it should only affect behaviour when toggling fullscreen
(including the default toggle when -fs is specified). My best guess is
that perhaps vo_x11_nofs_sizepos needs to be under if(!vo_fs); you
consistently have it being unconditional, even in cases where the
previous code *was* conditional, so perhaps there's some reason I'm not
aware of... but if this is about restoring window size/position
correctly on returning from fullscreen, why would the code need to be
executed when not in fullscreen mode?

(The call which is producing the problem, for me, is presently at
libvo/vo_xv.c line 355 - in the (WinID < 0 && vo_window == None) block.
 From the little I can tell, this code will be executed exactly once per
video (or once per run with -fixed-vo), when creating a new window for
the video to go in; since the window cannot then be toggling back from
fullscreen, and no test for either fullscreen status or -fs is made at
that location, I don't understand why the change needs to be made there.
Certainly, placing that line under if(vo_fs) fixes my problem; from a
quick test, it appears to also allow the "incorrect window size in
non-first video after disabling fullscreen" problem to occur again, but
only with -fixed-vo. Interestingly, without -fixed-vo, I don't get that
problem even under r18717; it looks to me like it may be more a problem
with -fixed-vo than with anything else.)

> I guess it would be nice to be able to specify to mplayer how it
> should behave in these cases (e.g. only change window size when
> switching movie but not position - which looks bad in some cases - or
> keep window center the same as before etc.), because I do not know of
> a behaviour that will satisfy everyone.
> 
> Suggestions welcome though.

When I'm sure I understand the situation, I will be very glad to provide
them.

> Until then, -geometry will have to do.

<sigh> Excessively extensive experimentation ahead, apparently... always
aggravating...

-- 
       The Wanderer (ahh, alliteration)

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.



More information about the MPlayer-cvslog mailing list