[MPlayer-dev-eng] Fast OpenGL playback

[The Wanderer]

D Richard Felker III wrote:

> On Tue, Nov 09, 2004 at 02:56:28PM -0500, The Wanderer wrote:
> 
>> Jan Knutar wrote:
>> 
>>> On Tuesday 09 November 2004 21:19, The Wanderer wrote:
>>> 
>>>> results - for, again, 300 frames apiece - are below in
>>>> increasing order of speed, averaged from three runs each. (A
>>>> couple of these were included just for the heck of it.)
>>> 
>>> Were you looking at the VC or VO cpu usage columns?
>> 
>> The VO column - or at least I believe that's what it was; the
>> second of the five numbers, counting left-to-right.
> 
> you need to use the sum or both. with different vo's, the time will
> get spent in different places. vesa definitely uses a LOT more cpu
> time than vidix or even xv (with a proper xv driver) because it has
> to do colorspace conversion.

Acknowledged; retesting.

New table, in decreasing order of the sum of the two values:

                   VC      VO      sum
gl              ~1.334   3.76   ~5.094  (hitch adds half-second to VC)
gl:manyfmts     ~0.929  ~3.627  ~4.556  (hitch adds half-second to VC)
caca            ~0.69   ~3.821  ~4.512
gl2             ~0.971  ~3.410  ~4.381  (hitch adds half-second to VC)
xvidix          ~0.963  ~0.662   1.625  (window displayed only solid 
green - colorkey ff00?)
x11             ~0.797  ~0.795  ~1.592
cvidix          ~0.884   0.635  ~1.519  (no display, 'DHA kernelhelper 
failed' messages)
aa               0.932   0.389   1.321
vesa             1.134  ~0.002  ~1.136
sdl             ~0.640  ~0.417  ~1.056
xv               0.611   0.429   1.04
null            ~0.397   0.001  ~0.398

The comment "hitch adds half-second to VC" refers to the fact that, if I
have done much of anything (including sometimes as little as switching
window focus) since last running MPlayer with one of these VO methods,
there will be a brief "hang" right after beginning playback; the net
effect this has on the benchmark is to add approximately one-half second
to the VC value. The numbers given are from runs in which this did not
happen.

The three GLs are, as I by now expect, the slowest (barring CACA, which
isn't that serious a VO method). XVIDIX is slightly faster than X11,
which is slightly faster than CVIDIX; AAlib is faster than all of those.

VESA does, in fact, use more total CPU time than does XV, but only by
about a tenth of a second - hardly what I'd call significant, given the
times turned in by the other methods. It also uses less time than does
either form of VIDIX, by around half a second. which while not
necessarily that significant is also not exactly negligible.

Whether anyone else has found this whole thing interesting or not, I
think I've found it somewhat informative...

-- 
       The Wanderer

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

A government exists to serve its citizens, not to control them.