gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] What remains to get re-entrant VM?


From: Richard Wilbur
Subject: Re: [Gnash-dev] What remains to get re-entrant VM?
Date: Thu, 22 Jan 2015 09:48:35 -0700

On Thu, Jan 22, 2015 at 3:11 AM, Sandro Santilli <address@hidden> wrote:
> On Wed, Jan 21, 2015 at 03:31:52PM -0700, Richard Wilbur wrote:
>> My understanding of the roadblocks in the way of supporting AVM2 was
>> that a major one was re-entrance of the VM.
>>
>> Has that been achieved?
>
> I think it was achieved, [...]

You are right, it looks like most of the re-entrance work is complete
in gnash.  Here's what I found with a little research on the mailing
list archive:

Regarding "Implementing ExternalInterface":
"If it doesn't scare you too much, working on the reentrant core lib
is the most useful thing to do." --strk (20090711)[1]

Core libraries re-entrant => "The [unimplemented] possibilities that
this opens up are:
- A real, windowless browser plugin (that also consumes less memory).
- A browser plugin on Windows.
- Better integration with other projects such as Lightspark.
- GUIs that can open several SWFs successively.
- Useful python or PHP modules for controlling SWF execution.
- More powerful utilities for producing screenshots, converting to video
etc." -- bwy (20101010)[2]

With Gnash 0.8.9 release announcement:
" * Re-entrant core libraries. Now Gnash is no longer dependent on a
   singleton Virtual Machine and Garbage Collector." --rob (20110319)[3]

"I've submitted a project on pubsoft.org for implementing a Gnash
windowless mode plugin[....]  A windowless mode plugin would be an
in-process plugin, now possible
thanks to the re-entrant interface Benjamin worked on.

Windowless plug-ins extend the possibilities for web page design and
functionalities.  Any web site relying on these extensions currently
fails with Gnash." -- strk (20110802)[4]


> I think it was achieved, although there's no automated testcase
> nor usage pattern showing it clearly. An example of such usage
> would be the implementation of a windowed NPAPI plugin which would
> also solve many navigation issues.

1.  So how is a "windowed NPAPI plugin" different from the current
Firefox plugin?
2.  What API does the current Firefox plugin implement?
3.  How does a "windowed NPAPI plugin" relate to the "windowless mode
plugin" you proposed back in 2011?
4.  I found a description of NPAPI[5], what other documentation would
you recommend I look at?

> A simpler one would be allowing
> the specification of multiple input files from the commandline and
> playing them all at once (or serially, with an option).
>

Should I use several existing swf files that already have tests and
rig it up to run simultaneously (or serially, with an option)?

> For AVM2 you could start
> by looking at lightspark, which does _only_ AVM2 and supports
> Gnash as a fallback for AVM1 apps. Making lightspark embeddable
> in Gnash could also be an interesting idea, to do the reverse.

I guess I'll try using lightspark to access sites that require AVM2
support and see how well they fare on lightspark.  Then, if there is
sufficient merit, I could look at what lightspark did to implement
AVM2 with an eye to implementing the same functionality in gnash.

Sincerely,
Richard

References:

[1]  http://lists.gnu.org/archive/html/gnash-dev/2009-07/msg00011.html
"[Gnash-dev] Implementing ExternalInterface"
[2]  http://lists.gnu.org/archive/html/gnash-dev/2010-10/msg00003.html
"[Gnash-dev] Gnash libraries"
[3]  http://lists.gnu.org/archive/html/gnash-dev/2011-03/msg00066.html
"[Gnash-dev] Gnash 0.8.9 released!"
[4]  http://lists.gnu.org/archive/html/gnash-dev/2011-08/msg00001.html
"[Gnash-dev] Fundraising for windowless mode plugin"
[5]  http://en.wikipedia.org/wiki/NPAPI



reply via email to

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