[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash] MX components, antialiasing with openGL
From: |
strk |
Subject: |
Re: [Gnash] MX components, antialiasing with openGL |
Date: |
Thu, 11 Jan 2007 14:49:27 +0100 |
On Thu, Jan 11, 2007 at 02:21:59PM +0100, Jacques Guillou wrote:
> Hi,
>
> I'm currently doing some investigation on Gnash 0.7.2 (linux) to see whether
> it would be a good choice for the embedded system (x86 based) we are working
> on.
> After a few tests, I have realized that it fails to render some of our SWF
> files correctly. When activating the traces (-vp) I can notice that some
> classes are not found :
> 14:01:52: ERROR: find_target("mx.data.components") failed
> 14:01:52: ERROR: find_target("mx.skins.halo") failed
> 14:01:52: ERROR: find_target("mx.core.ext") failed
> 14:01:52: ERROR: find_target(" mx.core") failed
>
> I've tried to export my files for flash 6 and also flash 7 but both
> solutions fail.
>
> Does it means it's not possible to use any MX component with the current
> version of Gnash ?
If MX component are supposed to be present in the player: yes.
Gnash doesn't provide them.
> Is there a way to embbed these classes into the SWF (an export setting of
> the Flash IDE) ?
Are you sure they aren't already ? Does -va show any attempt at
defining a 'mx' variable ?
> Which export settings of flash produce the most Gnash compatible SWF ?
5 should be feature-complete in terms of provided player classes.
SWF parsing by itself should go up to 7.
> The openGL rendering is really fast (which is exactly why we are interested
> in that software) but the quality is low. Is there any possibility to
> activate a global antialiasing (by rendering into a large image buffer and
> then downscaling the result so that it fits into the target screen). I've
> read somewhere that antialiasing should work for text rendering but it
> doesn't seem to work here.
Text antialiasing has been broken since we implemented incremental loading
(play while loading). Since AGG does fine w/out a prior rendering of glyphs
nobody found this an urgent task to follow, anywan there's a task filed
for this: https://savannah.gnu.org/task/?5998
Have you tried AGG for a comparison ?
--strk;