Re: [Gnash-dev] XVideo test

[Craig Kelley]

On Thu, Feb 26, 2009 at 3:01 AM, strk <address@hidden> wrote:

> I successfully built gnash with XVideo support
> and did some testing.
>
> Interestingly enough, the orisinal's game Winter Bells
> http://www.ferryhalim.com/orisinal/g3/00bells.swf
> reveals XVideo not only producing worst quality but also
> performing worst.

It all depends on the capabilities of your hardware.  If gnash has to
do colorspace conversions before handing it off, it will use the
general-purpose CPU to do so.  With Intel and Nvidia chipsets, you
have very good odds of an RGB32 adapter -- but many ATI cards only
support planar modes (YUV), and AGG cannot output anything but RGB
right now, so each frame has to go through a matrix manipulation if
that is the case.

About the quality -- the original gtk version that I wrote would
blindly accept the stage size as defined by the SWF and then blow it
out to the user's desired window size.  It didn't keep aspect ratio,
but that would be easy to add (and I seem to remember some aspect
ratio code already in gnash?).  Although, I'm not certain how Gnash
would know the physical dimensions of the screen (many 16:9 monitors
have a 1024x768 pixel size underneath).  So, if the original stage
size is small, and you're looking at it blown up, you're seeing a
simple pixel scaling and you will notice "jaggies".  With video, it
should not matter because the hardware and AGG/libmedia will do
exactly the same thing.  With vector graphics, you will notice.

I couldn't get 00bells.swf to run with the latest branch-0.8.5-pre
checkout, so I can't see what you're seeing (and it doesn't work with
0.8.3-xvideo either).  :-(

Adobe solves this problem by allowing the user to turn on/off
"hardware acceleration" in the player.  They also only ever enable it
when the flash uses the fullscreen FS command -- although AS3 has a
more fine-grained approach.

-- 
http://inconnu.islug.org/~ink finger address@hidden for PGP block