gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Contributing to gnash


From: niraj kulkarni
Subject: Re: [Gnash-dev] Contributing to gnash
Date: Fri, 16 Dec 2011 19:07:08 +0530

Thanks for response guys. Regarding localisation, my mothertongue is already listed in sugerlabs translation page. So I can get started on it immediately.

Regarding bugs, I would prefer to start on compatibility bugs. I've seen one bug report in bug tracker. I would definitely need your guidance regarding its debugging.

Regards
Niraj

On Fri, Dec 16, 2011 at 12:53 PM, Sandro Santilli <address@hidden> wrote:
On Thu, Dec 15, 2011 at 10:31:49AM +0530, niraj kulkarni wrote:
> Hi,
>       I would like to join gnash developers community and contribute to its
> development. So can you tell me some debugging guidelines as well as
> trivial tasks which will help me get started?

Hello Niraj, thank you for your interest in Gnash !

I'm not sure we ever wrote a general guideline to debugging SWF playback,
maybe your first contribution could be drafting a wiki page about that ?
http://wiki.gnashdev.org

There are two kind of bugs you may want to debug:

 (1) compatibility bugs
 (2) performance bugs

1. compatibility bugs

 It starts with an application not doing what it is supposed to do and
 from there the goal is finding _what_ exactly it should do and why it
 isn't doing it :)

 There's a whole category of SWF movies that won't run because they require
 an AVM2 implementation which Gnash doesn't have. But there are also many
 cases of SWF versions up to 7 which are _supposed_ to work and don't.

 I'm sure many of these are on the bug tracker so you may want to start
 with one of them and focus on it. Feel free to ask here if you find one
 which you think you'd enjoy working on. If you don't find any, consider
 stepping by an online game website and I'm sure you'll find one (as long
 as it does NOT require AVM2 ( File->Properties would tell you)).

2. performance bugs

 Playback takes up too much RAM or CPU. This is much harder to debug in that
 attempts to improve performances may introduce compatibility issue unless
 you've a very good knowledge of the codebase. In any case asking on the
 mailing list helps you reducing the risk.


In both cases automated tests for compatibility are of the upmost importance
to avoid breaking something by trying to fix something else. There is some
information about how our testsuite work in the gnash manual.

More informations about testing: http://wiki.gnashdev.org/Testing/QA

--strk;

 ,------o-.
 |   __/  |    Thank you for PostGIS-2.0 Topology !
 |  / 2.0 |    http://www.pledgebank.com/postgistopology
 `-o------'



reply via email to

[Prev in Thread] Current Thread [Next in Thread]