Re: nspluginwrapper (was: Re: Wow... (-- blown away at performance))
On Saturday 23 April 2011 04:11 pm, Benjamin Kaduk wrote: On Thu, 31 Mar 2011, Benjamin Kaduk wrote: On Thu, 31 Mar 2011, Jung-uk Kim wrote: On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Yes, this is a fork, but he is serious about cleaning up the code and is planning to become the new upstream. He was actually just in the office here this afternoon commenting how introducing a feature to configure that causes unknown options to be errors would cause most distros' packaging to break. Please do continue to follow it, as I expect it will come to fruition. Replying to this old thread, David tells me he has rolled a release, and has gained the old maintainer's blessing: http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-Apri l/msg6.html http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-Apri l/msg3.html www/nspluginwrapper-devel is updated to 1.3.2. Cheers, Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
nspluginwrapper (was: Re: Wow... (-- blown away at performance))
On Thu, 31 Mar 2011, Benjamin Kaduk wrote: On Thu, 31 Mar 2011, Jung-uk Kim wrote: On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Yes, this is a fork, but he is serious about cleaning up the code and is planning to become the new upstream. He was actually just in the office here this afternoon commenting how introducing a feature to configure that causes unknown options to be errors would cause most distros' packaging to break. Please do continue to follow it, as I expect it will come to fruition. Replying to this old thread, David tells me he has rolled a release, and has gained the old maintainer's blessing: http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-April/msg6.html http://www.redhat.com/archives/nspluginwrapper-devel-list/2011-April/msg3.html -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
Quoting Jung-uk Kim j...@freebsd.org (from Wed, 30 Mar 2011 12:50:04 -0400): Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try GDK_NATIVE_WINDOWS Flash on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. If you want me to generate a FreeBSD specific linux-f10-gtk just give me a heads-up with a patch which applies to the currently used gtk version. Bye, Alexander. -- Ankh if you love Isis. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Thursday 31 March 2011 01:58 am, Jung-uk Kim wrote: I wrote an ugly but very simple workaround. Drop the attached patch in www/nspluginwrapper-devel/files and replaces old one, rebuild, reinstall, redo plugin wrappers, etc., etc... I just went ahead and committed slightly improved version of this patch (nspluginwrapper-1.3.0_9) for the right-click hang problem. FYI... Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Thu Mar 31 11, Jung-uk Kim wrote: On Thursday 31 March 2011 01:58 am, Jung-uk Kim wrote: I wrote an ugly but very simple workaround. Drop the attached patch in www/nspluginwrapper-devel/files and replaces old one, rebuild, reinstall, redo plugin wrappers, etc., etc... I just went ahead and committed slightly improved version of this patch (nspluginwrapper-1.3.0_9) for the right-click hang problem. thanks. i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper FYI... Jung-uk Kim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: On Thu Mar 31 11, Jung-uk Kim wrote: On Thursday 31 March 2011 01:58 am, Jung-uk Kim wrote: I wrote an ugly but very simple workaround. Drop the attached patch in www/nspluginwrapper-devel/files and replaces old one, rebuild, reinstall, redo plugin wrappers, etc., etc... I just went ahead and committed slightly improved version of this patch (nspluginwrapper-1.3.0_9) for the right-click hang problem. thanks. i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Thu, 31 Mar 2011, Jung-uk Kim wrote: On Thursday 31 March 2011 02:27 pm, Alexander Best wrote: i just noticed the WWW links in pkg-descr of boths nspluginwrapper and nspluginwrapper-devel are broken. i believe [1] is the current location. cheers. alex [1] https://github.com/davidben/nspluginwrapper No, this is actually a fork. The original author disappeared and this guy picked it up from the last snapshot release. Please note there was no official release from this tree yet. If this guy actually produces something useful, www/nspluginwrapper-devel may switch later, of course. Yes, this is a fork, but he is serious about cleaning up the code and is planning to become the new upstream. He was actually just in the office here this afternoon commenting how introducing a feature to configure that causes unknown options to be errors would cause most distros' packaging to break. Please do continue to follow it, as I expect it will come to fruition. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wednesday 30 March 2011 12:46 am, Buganini wrote: It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ Don't do that is not an answer, I guess? ;-) Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try GDK_NATIVE_WINDOWS Flash on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. There was another attempt by PC-BSD to address this issue: http://trac.pcbsd.org/changeset/3799 Unfortunately, I have no idea how Pango can affect the right click problem in the first place. In fact, I wasn't able to reproduce the fix on FreeBSD (long ago) and I *thought* their fix is PBI-specific (kmoore added to CC list). Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wednesday 30 March 2011 12:50 pm, Jung-uk Kim wrote: On Wednesday 30 March 2011 12:46 am, Buganini wrote: It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ Don't do that is not an answer, I guess? ;-) Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try GDK_NATIVE_WINDOWS Flash on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. There was another attempt by PC-BSD to address this issue: http://trac.pcbsd.org/changeset/3799 Unfortunately, I have no idea how Pango can affect the right click problem in the first place. In fact, I wasn't able to reproduce the fix on FreeBSD (long ago) and I *thought* their fix is PBI-specific (kmoore added to CC list). I forgot one important thing. Actually, this problem only started happening from Flash plugin 10.1. So, the easist workaround is going back to the last 10.0 release (e.g., 10.0.45.2 does not have this issue). You can find old versions from here: http://kb2.adobe.com/cps/142/tn_14266.html FYI, the following Chromium PR has the most plausible root-cause analysis of this problem I've ever seen on the Net: http://code.google.com/p/chromium/issues/detail?id=40157 Just in case if anyone is capable and willing to fix it for good... Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On 03/30/2011 12:50, Jung-uk Kim wrote: On Wednesday 30 March 2011 12:46 am, Buganini wrote: It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ Don't do that is not an answer, I guess? ;-) Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try GDK_NATIVE_WINDOWS Flash on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. There was another attempt by PC-BSD to address this issue: http://trac.pcbsd.org/changeset/3799 Unfortunately, I have no idea how Pango can affect the right click problem in the first place. In fact, I wasn't able to reproduce the fix on FreeBSD (long ago) and I *thought* their fix is PBI-specific (kmoore added to CC list). Jung-uk Kim I checked the other day, and our pango fix is no longer functional, that was something we did for flash 9 back in the day and it seemed to fix the right-click functionality for our PBIs, but alas, no more. We are in the same boat as you at the moment. -- Kris Moore PC-BSD Software iXsystems ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wed Mar 30 11, Jung-uk Kim wrote: On Wednesday 30 March 2011 12:50 pm, Jung-uk Kim wrote: On Wednesday 30 March 2011 12:46 am, Buganini wrote: It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ Don't do that is not an answer, I guess? ;-) Seriously, this problem is very well known. There were several work-arounds suggested but the most popular one is setting GDK_NATIVE_WINDOWS environment variable. Try GDK_NATIVE_WINDOWS Flash on Google and you will see tons of them. Actually, Fedora took that hack into nspluginwrapper later: https://bugzilla.redhat.com/show_bug.cgi?id=542424 Basically, Gnome people broke the ABI in the middle of major release branch, if my understanding is correct. Of course, that caused a lot of complaints and they had to add the variable to restore the previous behavior. Now here is the bad news for you. This environment variable does nothing for us because linux-f10-gtk2-2.14.7 does not have the compat hack. :-( One thing we can do is re-rolling linux-f10-gtk2 with the hack locally (as we did for x11-toolkits/linux-f10-pango) and using the hack from www/nspluginwrapper-devel *iff* that actually fixes the problem. There was another attempt by PC-BSD to address this issue: http://trac.pcbsd.org/changeset/3799 Unfortunately, I have no idea how Pango can affect the right click problem in the first place. In fact, I wasn't able to reproduce the fix on FreeBSD (long ago) and I *thought* their fix is PBI-specific (kmoore added to CC list). I forgot one important thing. Actually, this problem only started happening from Flash plugin 10.1. So, the easist workaround is going back to the last 10.0 release (e.g., 10.0.45.2 does not have this issue). You can find old versions from here: just wanted to report that the bug still exists in flash 11. http://kb2.adobe.com/cps/142/tn_14266.html FYI, the following Chromium PR has the most plausible root-cause analysis of this problem I've ever seen on the Net: http://code.google.com/p/chromium/issues/detail?id=40157 Just in case if anyone is capable and willing to fix it for good... Jung-uk Kim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wednesday 30 March 2011 04:54 pm, Alexander Best wrote:
On Wed Mar 30 11, Jung-uk Kim wrote:
On Wednesday 30 March 2011 12:50 pm, Jung-uk Kim wrote:
On Wednesday 30 March 2011 12:46 am, Buganini wrote:
It seems work well now, no lockup when I went through pages.
but I still got lockup when I right-click on some flash
advertisement. for example, here: http://tw.yahoo.com/
Don't do that is not an answer, I guess? ;-)
Seriously, this problem is very well known. There were several
work-arounds suggested but the most popular one is setting
GDK_NATIVE_WINDOWS environment variable. Try
GDK_NATIVE_WINDOWS Flash on Google and you will see tons of
them. Actually, Fedora took that hack into nspluginwrapper
later:
https://bugzilla.redhat.com/show_bug.cgi?id=542424
Basically, Gnome people broke the ABI in the middle of major
release branch, if my understanding is correct. Of course,
that caused a lot of complaints and they had to add the
variable to restore the previous behavior. Now here is the bad
news for you. This environment variable does nothing for us
because
linux-f10-gtk2-2.14.7 does not have the compat hack. :-(
One thing we can do is re-rolling linux-f10-gtk2 with the hack
locally (as we did for x11-toolkits/linux-f10-pango) and using
the hack from www/nspluginwrapper-devel *iff* that actually
fixes the problem.
There was another attempt by PC-BSD to address this issue:
http://trac.pcbsd.org/changeset/3799
Unfortunately, I have no idea how Pango can affect the right
click problem in the first place. In fact, I wasn't able to
reproduce the fix on FreeBSD (long ago) and I *thought* their
fix is PBI-specific (kmoore added to CC list).
I forgot one important thing. Actually, this problem only
started happening from Flash plugin 10.1. So, the easist
workaround is going back to the last 10.0 release (e.g.,
10.0.45.2 does not have this issue). You can find old versions
from here:
just wanted to report that the bug still exists in flash 11.
I wrote an ugly but very simple workaround. Drop the attached patch
in www/nspluginwrapper-devel/files and replaces old one, rebuild,
reinstall, redo plugin wrappers, etc., etc...
Cheers,
JK
http://kb2.adobe.com/cps/142/tn_14266.html
FYI, the following Chromium PR has the most plausible root-cause
analysis of this problem I've ever seen on the Net:
http://code.google.com/p/chromium/issues/detail?id=40157
Just in case if anyone is capable and willing to fix it for
good...
Jung-uk Kim
--- src/npw-wrapper.c.orig 2011-03-30 19:53:27.0 -0400
+++ src/npw-wrapper.c 2011-03-30 19:54:15.0 -0400
@@ -30,6 +30,7 @@
#include unistd.h
#include signal.h
#include semaphore.h
+#include signal.h
#include sys/wait.h
#include glib.h
@@ -2560,6 +2561,24 @@
return ret;
}
+#defineNPW_ADOBE_FLASH_NAMEShockwave Flash
+
+// Detect Adobe Flash plugin version
+static float is_adobe_flash(void)
+{
+ static float version = 0.0;
+ static bool tested = false;
+
+ if (!tested) {
+ if (strcmp(g_plugin.name, NPW_ADOBE_FLASH_NAME) == 0
+ strncmp(g_plugin.description, NPW_ADOBE_FLASH_NAME,
+ strlen(NPW_ADOBE_FLASH_NAME)) == 0)
+ version = strtof(g_plugin.description +
strlen(NPW_ADOBE_FLASH_NAME), NULL);
+ tested = true;
+ }
+ return version;
+}
+
static int16 g_NPP_HandleEvent(NPP instance, void *event)
{
if (instance == NULL)
@@ -2569,6 +2588,13 @@
if (plugin == NULL)
return NPERR_INVALID_INSTANCE_ERROR;
+ if (((NPEvent *)event)-type == ButtonPress
+ ((XButtonEvent *)event)-button == Button3
+ is_adobe_flash() = 10.1) {
+ /* XXX: work around right click hang with Flash plugin 10.1 and later
*/
+ D(bug(NPP_HandleEvent instance=%p: Button3 pressed on SWF\n,
instance));
+ return true;
+ }
if (((NPEvent *)event)-type == GraphicsExpose) {
/* XXX: flush the X output buffer so that the call to
gdk_pixmap_foreign_new() in the viewer can work */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper yaneg...@gmail.com wrote: Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. Regards, Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wed Mar 30 11, Buganini wrote: Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper yaneg...@gmail.com wrote: Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. i was able to build the latest nspluginwrapper version via github [1]. however i cannot install any plugins due to the following error: nspluginwrapper: no appropriate viewer found for /home/arundel/.mozilla/plugins/libflashplayer.so [1] https://github.com/davidben/nspluginwrapper Regards, Buganini -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: On Wed Mar 30 11, Buganini wrote: Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper yaneg...@gmail.com wrote: � �Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. i was able to build the latest nspluginwrapper version via github [1]. however i cannot install any plugins due to the following error: nspluginwrapper: no appropriate viewer found for /home/arundel/.mozilla/plugins/libflashplayer.so [1] https://github.com/davidben/nspluginwrapper Update your ports, install www/nspluginwrapper-devel, reinstall your plugins, and enjoy. ;-) Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue Mar 29 11, Jung-uk Kim wrote: On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: On Wed Mar 30 11, Buganini wrote: Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper yaneg...@gmail.com wrote: ??? ???Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. i was able to build the latest nspluginwrapper version via github [1]. however i cannot install any plugins due to the following error: nspluginwrapper: no appropriate viewer found for /home/arundel/.mozilla/plugins/libflashplayer.so [1] https://github.com/davidben/nspluginwrapper Update your ports, install www/nspluginwrapper-devel, reinstall your plugins, and enjoy. ;-) whooo. thanks a bunch. :) Jung-uk Kim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wed Mar 30 11, Alexander Best wrote: On Tue Mar 29 11, Jung-uk Kim wrote: On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: On Wed Mar 30 11, Buganini wrote: Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper yaneg...@gmail.com wrote: ??? ???Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. i was able to build the latest nspluginwrapper version via github [1]. however i cannot install any plugins due to the following error: nspluginwrapper: no appropriate viewer found for /home/arundel/.mozilla/plugins/libflashplayer.so [1] https://github.com/davidben/nspluginwrapper Update your ports, install www/nspluginwrapper-devel, reinstall your plugins, and enjoy. ;-) whooo. thanks a bunch. :) getting between 25 and 30 fps on 720p youtube flicks without hw acceleration running flash 11,0,0,60. also nspluginwrapper hasn't crashed since yet. looking really well. :) Jung-uk Kim -- a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue, Mar 29, 2011 at 7:21 PM, Alexander Best arun...@freebsd.org wrote: On Wed Mar 30 11, Alexander Best wrote: On Tue Mar 29 11, Jung-uk Kim wrote: On Tuesday 29 March 2011 05:35 pm, Alexander Best wrote: On Wed Mar 30 11, Buganini wrote: Could this help? https://bugzilla.redhat.com/show_bug.cgi?id=680279 On Wed, Feb 23, 2011 at 12:29 AM, Garrett Cooper yaneg...@gmail.com wrote: ??? ???Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. the fix is included in the latest nspluginwrapper-devel update, i'm going to try it. i was able to build the latest nspluginwrapper version via github [1]. however i cannot install any plugins due to the following error: nspluginwrapper: no appropriate viewer found for /home/arundel/.mozilla/plugins/libflashplayer.so [1] https://github.com/davidben/nspluginwrapper Update your ports, install www/nspluginwrapper-devel, reinstall your plugins, and enjoy. ;-) whooo. thanks a bunch. :) getting between 25 and 30 fps on 720p youtube flicks without hw acceleration running flash 11,0,0,60. also nspluginwrapper hasn't crashed since yet. looking really well. :) Jung-uk Kim -- a13x -- a13x I've been visiting sites which normally cause problems, sites which normally force me to run the infamous `killall npviewer.bin`. I haven't experienced a single lock-up so far (nor have I seen ANY hiccups). Also, the flash objects load rather quickly; very cool... -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
It seems work well now, no lockup when I went through pages. but I still got lockup when I right-click on some flash advertisement. for example, here: http://tw.yahoo.com/ and notice that if your browser doesn't have flashplayer installed, the website will use js instead. Regards, Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable:
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable:
Re: Wow... (-- blown away at performance)
On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers.
Re: Wow... (-- blown away at performance)
On Wed Feb 23 11, John Baldwin wrote: On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second
Re: Wow... (-- blown away at performance)
On 22/02/2011 23:33, Alexander Best wrote: Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. While on the subject - any ideas why npviewer.bin is present as so many processes? They all appear to have some identical properties, most curiously their memory usage, so shouldn't they be threads? betelgeuse:~ ps axu | grep npv ivoras 7775 0.0 1.3 695332 55760 ?? S 8:03pm 0:11.84 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7787 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.86 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7788 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7789 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7790 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7791 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7792 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7793 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.51 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7794 0.0 1.3 695332 55760 ?? I 8:03pm 0:00.00 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7795 0.0 1.3 695332 55760 ?? S 8:03pm 0:00.01 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7796 0.0 1.3 695332 55760 ?? I 8:03pm 0:00.44 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7797 0.0 1.3 695332 55760 ?? S 8:03pm 0:03.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7798 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7799 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7800 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7801 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.38 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7802 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7803 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7804 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7805 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.38 /usr/local/lib/ns ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Wed Feb 23 11, John Baldwin wrote: On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second
Re: Wow... (-- blown away at performance)
On Wednesday, February 23, 2011 2:11:35 pm Ivan Voras wrote: On 22/02/2011 23:33, Alexander Best wrote: Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. While on the subject - any ideas why npviewer.bin is present as so many processes? They all appear to have some identical properties, most curiously their memory usage, so shouldn't they be threads? Threads in Linux processes show up as individual processes. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On 23 February 2011 21:17, John Baldwin j...@freebsd.org wrote: On Wednesday, February 23, 2011 2:11:35 pm Ivan Voras wrote: On 22/02/2011 23:33, Alexander Best wrote: Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. While on the subject - any ideas why npviewer.bin is present as so many processes? They all appear to have some identical properties, most curiously their memory usage, so shouldn't they be threads? Threads in Linux processes show up as individual processes. Ah, ok. This was fixed in Linux (in their nptl project cca 2005) so I assumed it was also fixed here. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex Thanks, -Garrett -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex Have you found any method or workaround to mitigate this issue? -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex Have you found any method or workaround to mitigate this issue? no. i've increased the kern.threads.max_threads_per_proc value, but that had no effect. so it
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex Have you
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second
Re: Wow... (-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second
Re: Wow... (-- blown away at performance)
On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Alexander Best wrote: On Tue Feb 22 11, Brandon Gooch wrote: On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best arun...@freebsd.org wrote: On Tue Feb 22 11, Garrett Cooper wrote: On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym eir...@gmail.com wrote: On 22 February 2011 11:15, Garrett Cooper yaneg...@gmail.com wrote: I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be up to 85% on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable:
