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?