From gb.public at free.fr Thu Jan 1 22:12:09 2009
From: gb.public at free.fr (Gwenole Beauchesne)
Date: Thu, 1 Jan 2009 23:12:09 +0100
Subject: NPRuntime data caching
Message-ID: <470DF0F3-E0D9-4E0C-96EA-2527423503A6@free.fr>
Hi,
FYI, nspluginwrapper 1.3.0 performance improvements focused on the
following testcase:
The browser is calling NPPVpluginScriptableNPObject methods
(GetVariable 'PercentLoaded' et al.) many times. This results in
excessive RPC for NPClass::HasProperty(), NPClass::HasMethod(),
NPN_UTF8FromIdentifier(). So, I decided to add some caching for those.
It's not really possible to fully cache NPClass::HasProperty() because
there is no means to get notified when the property changes. However,
my strategy is to assume the set of methods in an NPObject doesn't
change at run-time, so we can guess something is not a property if we
know it is a method for example. Based on this information, and with
another level of caching for NPIdentifiers, here are the initial
results.
Without NPRuntime data caching:
*** NSPlugin Viewer *** RPC overhead: 1,37% (2,458 sec / 179,850 sec)
*** NSPlugin Viewer *** RPC transfer: 2048820 bytes (1290671 recv,
758149 send)
With NPRuntime data caching:
*** NSPlugin Viewer *** RPC overhead: 0,52% (0,930 sec / 180,567 sec)
*** NSPlugin Viewer *** RPC transfer: 677978 bytes (475629 recv,
202349 send)
This means RPC transfers reduced by around two thirds, that's an
interesting gain. Global RPC overhead is now around 0.5% with that
particular testcase. This means the npviewer.bin process can sleep
slightly longer. Unfortunately, there is no public tools available yet
to evaluate the gain in energy. So the expectation is that, in the
long run, fans of my notebook calm down. ;-) In the end, we will
always be limited by the actual plug-in work anyway.
nspluginwrapper 1.3.2 will probably focus on streams and windowless
mode performance.
Note: NPIdentifiers could be optimized further, but this would require
to use a garbage collector. The current implementation is competitive
enough anyway. The cache can contain up to 256 entries. In practise, only needed two.
Regards,
Gwenole.
From gb.public at free.fr Thu Jan 1 22:20:23 2009
From: gb.public at free.fr (Gwenole Beauchesne)
Date: Thu, 1 Jan 2009 23:20:23 +0100
Subject: sleep-patch (Was: [ANN] nspluginwrapper 1.2.0)
In-Reply-To: <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr>
References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr>
<495550E0.5060507@redhat.com>
<53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr>
Message-ID: <604A1A09-7FD7-4D14-8EFB-544ED5BBAB28@free.fr>
Hi,
Le 27 d?c. 08 ? 08:28, Gwenole Beauchesne a ?crit :
>> http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.2-event.patch?revision=1.1
>> What does this do? Not suitable for upstream?
>
> Actually, nothing for Gtk2-based plugins like Adobe Reader or Adobe
> Flash. The initial intent was to purge all pending Xt timer or input
> events when they are available. I still plan another patch for 1.3.x
> series (1.4.0) that will also kill the Xt timer when it's not needed
> at all (Gtk2 plugins). This will avoid switching from sleep state
> too much, as initially intended in one of your bug reports.
There are now two things implemented in trunk:
- Get rid of raw X/Xt events polling if we know the plug-in is Gtk-
based (XEMBED)
- If the plug-in is Xt-based, we can further optimize this also by
getting rid of the 40Hz timer (tested for XtIMTimer and
XtIMAlternateInput only).
I have not measured the benefits of those changes yet. The expected
result is to lower the need to awake the npviewer.bin process too often.
Regards,
Gwenole.
From gb.public at free.fr Fri Jan 2 09:59:21 2009
From: gb.public at free.fr (Gwenole Beauchesne)
Date: Fri, 2 Jan 2009 10:59:21 +0100
Subject: [ANN] nspluginwrapper 1.2.2
References: <5FC9B372-ADA7-4B5E-B003-9F05DDA4FE05@splitted-desktop.com>
Message-ID:
Hi,
nspluginwrapper 1.2.2 is a bug-fixes only release from the
nspluginwrapper-1.2-branch.
Changes since 1.2.0:
* Fix support for the VLC plug-in (0.8.6)
* Fix memory deallocation in ''NPN_GetStringIdentifiers()''
* Fix return value if stream creation failed in standalone player
Files are available at:
BTW, nspluginwrapper-1.0-branch is now obsolete.
Regards,
Gwenole.
From gb.public at free.fr Fri Jan 2 15:46:39 2009
From: gb.public at free.fr (Gwenole Beauchesne)
Date: Fri, 2 Jan 2009 16:46:39 +0100
Subject: [ANN] nspluginwrapper 1.3.0
Message-ID: <3577EE03-0954-458C-848B-05B78476E50A@free.fr>
Hi,
nspluginwrapper 1.3.0, a development snapshot leading to 1.4.0, is now
available.
Changes from 1.2.2:
* Don't poll for Xt events in Gtk (XEMBED) plug-ins
* Use 40 Hz timer for Xt events only when necessary (Xt input sources)
* Add NPIdentifier and NPClass::HasMethod caches, i.e. lower RPC traffic
* Add support for multiple viewer paths, see --viewer-paths=PATH-EXPR
* Add basic checks for malloc()'ed buffer underflow/overflow
* Add checks for single-threaded calls into the browser (NPN_*()
functions)
Announcement and further details:
Regards,
Gwenole.
From wtogami at redhat.com Mon Jan 12 04:59:04 2009
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 11 Jan 2009 23:59:04 -0500
Subject: [ANN] nspluginwrapper 1.3.0
In-Reply-To: <3577EE03-0954-458C-848B-05B78476E50A@free.fr>
References: <3577EE03-0954-458C-848B-05B78476E50A@free.fr>
Message-ID: <496ACE18.1010306@redhat.com>
Gwenole Beauchesne wrote:
> Hi,
>
> nspluginwrapper 1.3.0, a development snapshot leading to 1.4.0, is now
> available.
>
> Changes from 1.2.2:
> * Don't poll for Xt events in Gtk (XEMBED) plug-ins
> * Use 40 Hz timer for Xt events only when necessary (Xt input sources)
> * Add NPIdentifier and NPClass::HasMethod caches, i.e. lower RPC traffic
> * Add support for multiple viewer paths, see --viewer-paths=PATH-EXPR
> * Add basic checks for malloc()'ed buffer underflow/overflow
> * Add checks for single-threaded calls into the browser (NPN_*() functions)
>
> Announcement and further details:
>
>
Been using this a few days, so far so good. Stransky reports that the
viewer_paths support was indeed helpful. Our patch deltas are much
smaller now.
http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/
We have 3 remaining patches. I hope we can eventually eliminate the
need for patches with further build options upstream.
Warren Togami
wtogami at redhat.com
From wtogami at redhat.com Tue Jan 13 03:41:08 2009
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 12 Jan 2009 22:41:08 -0500
Subject: Nspluginwrapper does not work with RealPlayer11GOLD
Message-ID: <496C0D54.4070409@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=479663
Nspluginwrapper does not work with RealPlayer11GOLD
http://www.real.com/linux
It appears that the download is here, although I haven't tried this myself.
Warren Togami
wtogami at redhat.com
From yaohan.chen at gmail.com Fri Jan 23 00:02:56 2009
From: yaohan.chen at gmail.com (Yaohan Chen)
Date: Thu, 22 Jan 2009 19:02:56 -0500
Subject: Some SWF movies/games do not work in npplayer (when they request
remote content?)
Message-ID: <200901221902.56952.yaohan.chen@gmail.com>
I am unable to play the Google video and "Magic Pen" flash game linked as
examples on
using nspluginplayer. The Google video shows a seek bar and stops there. The
flash game shows its loading screen with an nearly empty progress bar and also
stops. These flash movies work in Adobe standalone flash player and Konqueror
(which I think uses nspluginviewer) on the same computer.
I am able to use npplayer to play some small swf files and the difference seems
to be that they do not make remote data requests, but I am not sure.
I am on Ubuntu 8.10, with Adobe Flash plugin 10,0,15,3. I have tried with the
nspluginwrapper 1.1 deb package, as well as 1.2.2 and 1.3.0 built from source,
and all versions are having similar problems. I did not update the
nspluginwrapper installed on the system when trying 1.2.2 and 1.3.0 player; is
that necessary?