Closed Bug 392073 Opened 12 years ago Closed 6 years ago
Firefox limited to 1 CPU on multi-cpu machine; multi-threading appears broken
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20070725 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070725 Firefox/18.104.22.168 This isn't a new problem, but has come to stand out as a fairly major "booboo" as Firefox has more windows open and has become slower and less responsive. But firefox seems to be limited to 1 Core on a multi-way machine. I have a 2Px2Core setup (4 cores). Firefox's threading is broken in that it is constrained to 1 Core. Given that cores are increasing in number but CPU GHz is not, this is a "major bug". While it should be a goal, overall to decrease all resource usages, when it becomes necessary to use more resources, FF should be able to take advantage of *parallel* processing (running on more than one processor at a time). Reproducible: Always Steps to Reproduce: 1. ...happens spuriously & often; ... *any* CPU-bound operation 2. 3. Actual Results: Firefox performance is very bad (lockups 10-20 seconds at a time or more), but FF limited to "exactly" **25%** of my machine's CPU. I have a 2Processor x 2 Core machine (4 cores total). Even though firefox appears to be multithreaded, it doesn't use more than 1 Core at a time. Expected Results: I would expect a program that has multiple "independent" windows open at the same time (independent, meaning unrelated websites, for example). Firefox should not be limited to 1 CPU. I have both types of "multi-cpu" available: 2 physical processors in a dual-socket machine, and each socket containing a Core 2 Duo. Firefox seems unable to take advantage of modern multi-core CPU's. This is "terrible", since the trend in the recent past (and likely future), has been to drop clock speeds and double, quadruple or octuple CPU's. While I might have had option to find a 4GHz single CPU (P4), the current mode of expansion is to drop the clock (sometimes by 50%), and add more cores. Firefox is not taking advantage of multiple cores even though it *appears* to have multiple threads. According to ProcessExplorer, my FF process has *27* threads. Yet all of them seem to be constrained to running on 1 Core. I currently have Firefox's CPU affinity set to "CPU 0 + CPU 1" (I have cpu's 2 & 3 dedicated to an application which sit's idle when it doesn't have focus). But affin'ed to 2 or all 4 cores, FF still only uses 1 core (25% of CPU). This is just "broken". I expect FF to use more resources as I open more windows (in separate windows or, even, multiple tabs in each window). FF is using a substantial amount of resources (which I'm NOT complaining about in this report), but *refuses* to use more CPU than 25% (1 out 4 Cores). Other resource usage stats: memory: Working: 712MB(/721MB peak), Virtual:927MB, Private:734MB(741MB Peak); Handles: Sys:1104, GDI:1687, USER:1098 ---------
There's some discussion about it in bug 40848 and bug 384115. The problem is that most of the GUI runs in a single thread, and is therefor not really scalable. It would be *very* hard to change that. And then I'm not even talking about extensions and plugins.
Thanks for the pointers -- both bugs appear mostly inactive for a few months. It's amazing the lack of understanding around allowing multiple threads of execution. But more pertinent. I don't *think* the GUI would have to become multi-threaded to solve the problem. Where I *noticed* the problem the most was after Firefox had been *up* for a few days. I usually go to a news site like news.google, news.bbc.co.uk, or reuters.com. On the main page, I usually look over interesting articles and press "middle mouse (launch URL in background). I verified it just now -- there is an increasing slowness that parallels time that Firefox remains 'up'. With a fresh start, I can click several URL's within a few seconds and have them all start coming up in background. No prob. But after FF had been up (~a week?) (yeah, this is on XP2), the new-URL launch froze the UI for up to ~7-15 seconds per URL. Needless to say -- it really slows down launching articles of interest. So, really, that's one "aspect" that may be completely separate from any multi-threading. Don't know if it was due to a memory leak or what, but I know it wasn't paging (was only using ~900M out of 3G and wasn't close to limits. The second aspect, *I believe*, is that the GUI is processing "events" that are tasking "too much time" in processing certain GUI events that *should* be handed off to one or more execution (worker) threads. It's not like the GUI is displaying anything on the screen. It should gen tasks and hand them off to a queue. Events in the Queue could be, *optionally* marked as "execution barriers", meaning no other ops could be running while they are running, but the default should be allowing parallel event execution. That way, as many as possible parallel events could get the benefit of the new architecture, but those events that "don't play nice" in parallel with other threads could be marked as such. Even more advanced, threads might include "pre-events" that need to be processed before executing a given event and future events could be forced to wait for one or more dependencies. It floors me that FF can use 26 threads (obviously parts of FF are designed to operate in multiple threads), the *none* of the threads will execute on a separate core. Very strange...
Over to General for triage and adding dupeme
Component: Shell Integration → General
QA Contact: shell.integration → general
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME http://www.mozilla.com http://support.mozilla.com/kb/Managing+profiles http://support.mozilla.com/kb/Safe+mode
Whiteboard: [DUPEME] → [closeme 2010-05-25] [DUPEME]
Version: unspecified → 2.0 Branch
No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Is this bug still active under another bug number? I've seen this bug using versions 3.6.3, 4.0, etc. I haven't yet fully tested with 5.0, but I should know by the end of the day...
This is still a bug under firefox 3.6.18
Status: RESOLVED → UNCONFIRMED
OS: Windows XP → Windows 7
Hardware: x86 → x86_64
Resolution: INCOMPLETE → ---
Whiteboard: [closeme 2010-05-25] [DUPEME]
Version: 2.0 Branch → 3.6 Branch
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago → 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: multicore
This is not a duplicate of a meta-bug about future architecture. If there's a bad use of OS threading system calls, identify and fix. Cc'ing Rob Arnold in case he can comment. /be
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
brandan...so I see.... I was responding/acting in response to: -- Comment 4 Wayne Mery (:wsmwk) 2009-03-17 03:22:40 PDT L.A.Walsh, Can you dupe this to bug 277547 or bug 384115? --- bug 277547 didn't apply, and 384115 looked closer, so I chose it. Sorry, I shouldn't have blindly followed instructions.
Guess I opened 1 too many windows -- anyway FF hung, non-responsive for over 15 minutes -- enough time to copy down the stack traces of all the busy modules and their usage percent: module/prog (cpu usage) firefox.exe+0x1840 (99.76) ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KiCheckForKernelApcDelivery+0x25 ntoskrnl.exe!MmGetSystemRoutineAddress+0x2be78 ntoskrnl.exe!KeSynchronizeExecution+0x3a43 ntdll.dll!NtAllocateVirtualMemory+0xa wow64.dll!Wow64EmulateAtlThunk+0x2a45 wow64.dll!Wow64SystemServiceEx+0xd7 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!LdrpInitializeProcess+0x17e4 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!NtAllocateVirtualMemory+0x12 KERNELBASE.dll!VirtualAlloc+0x18 MOZCRT19.dll!@_realloc_crt@8+0xcf4 MOZCRT19.dll!_expand+0xfd9 MOZCRT19.dll!_expand+0x158f MOZCRT19.dll!malloc+0x53 xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x537b xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x5ca2 xul.dll!?InitTextRunUniscribe@gfxWindowsFontGroup@@IAEXPAVgfxContext@@PAVgfxTextRun@@PBGI@Z+0xd56 MOZCRT19.dll!_initptd+0x1b3 MOZCRT19.dll!_errno+0x5 ----- Other busy threads: sapi.dll!UnregisterServer+0x8c79f (m=million) (3total using 1%, .12%, and 1 <.06%: or (183m, 25m, .125m) Δcycles, ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForMultipleObjects+0x26a ntoskrnl.exe!NtWaitForSingleObject+0x40f ntoskrnl.exe!IoReportTargetDeviceChange+0xe61 ntoskrnl.exe!KeSynchronizeExecution+0x3a43 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForMultipleObjects+0x15 kernel32.dll!WaitForMultipleObjectsEx+0x8e sapi.dll!DllUnregisterServer+0x1545c sapi.dll!DllUnregisterServer+0x65134 sapi.dll!DllUnregisterServer+0x8c774 sapi.dll!DllUnregisterServer+0x8c815 kernel32.dll!BaseThreadInitThunk+0x12 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 ----------------- another busy one... MOZCRT19.dll!_endthreadex+0xa0 ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!NtWaitForSingleObject+0xde ntoskrnl.exe!KeSynchronizeExecution+0x3a43 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364firefox.exe+0x1840 (99.76) ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KiCheckForKernelApcDelivery+0x25 ntoskrnl.exe!MmGetSystemRoutineAddress+0x2be78 ntoskrnl.exe!KeSynchronizeExecution+0x3a43 ntdll.dll!NtAllocateVirtualMemory+0xa wow64.dll!Wow64EmulateAtlThunk+0x2a45 wow64.dll!Wow64SystemServiceEx+0xd7 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!LdrpInitializeProcess+0x17e4 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!NtAllocateVirtualMemory+0x12 KERNELBASE.dll!VirtualAlloc+0x18 MOZCRT19.dll!@_realloc_crt@8+0xcf4 MOZCRT19.dll!_expand+0xfd9 MOZCRT19.dll!_expand+0x158f MOZCRT19.dll!malloc+0x53 xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x537b xul.dll!?ForEachFontInternal@gfxFontGroup@@IAEHABVnsAString_internal@@ABVnsACString_internal@@HHP6AH01PAX@Z2@Z+0x5ca2 xul.dll!?InitTextRunUniscribe@gfxWindowsFontGroup@@IAEXPAVgfxContext@@PAVgfxTextRun@@PBGI@Z+0xd56 MOZCRT19.dll!_initptd+0x1b3 MOZCRT19.dll!_errno+0x5 ----- sapi.dll!UnregisterServer+0x8c79f (m=million) (3total using 1%, .12%, and 1 <.06%: or (183m, 25m, .125m) Δcycles, ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForMultipleObjects+0x26a ntoskrnl.exe!NtWaitForSingleObject+0x40f ntoskrnl.exe!IoReportTargetDeviceChange+0xe61 ntoskrnl.exe!KeSynchronizeExecution+0x3a43 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForMultipleObjects+0x15 kernel32.dll!WaitForMultipleObjectsEx+0x8e sapi.dll!DllUnregisterServer+0x1545c sapi.dll!DllUnregisterServer+0x65134 sapi.dll!DllUnregisterServer+0x8c774 sapi.dll!DllUnregisterServer+0x8c815 kernel32.dll!BaseThreadInitThunk+0x12 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 ----------------- MOZCRT19.dll!_endthreadex+0xa0 ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!NtWaitForSingleObject+0xde ntoskrnl.exe!KeSynchronizeExecution+0x3a43 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29364 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForSingleObject+0x15 kernel32.dll!WaitForSingleObjectEx+0x43 kernel32.dll!WaitForSingleObject+0x12 xul.dll!?GetTextUnicode@gfxTextRun@@QBEPBGXZ+0x1bac xul.dll!NS_Realloc_P+0xfe8 xul.dll!?ShrinkToLigatureBoundaries@gfxTextRun@@AAEXPAI0@Z+0x1838 xul.dll!XRE_main+0xda2f MOZCRT19.dll!_endthreadex+0x78 MOZCRT19.dll!_endthreadex+0x106 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 ---- + 2 more running sapi threads @ same addr (but not displayed)
Forgot to mention -- in above hang case, no windows were responsive. Had to kill process.
The stack trace from comment 12 looks like (if I had to take a wild stab), the kernel running some APC (deferred function call) related to the Firefox process. Second guess is a corrupted stack (hint is the misaligned_access with largish offsets and the stack starting at _errno+0x5) but it doesn't seem likely. EIther way, not clear how it's related to the original report so please file a new bug on that if you can reproduce it again. Now back to the original issue. A few things: 1) In 3.6.4+, plugins now run in their own process which gives some scaling to multi cores so you should see some of that (look for CPU usage in plugin-container.exe) 2) There's been a lot of work in Firefox 4+ to make use of more cores. Does this problem still occur if you upgrade? 3) There appear to be no calls to set the process or thread affinity in the Firefox source according to mxr so if that is the problem (can be verified with Process Explorer or the task manager I believe) either you've inherited this from the environment in which you launch Firefox or some 3rd party addon (extension, plugin, external program, etc...) is setting it.
FYI, here's a stack trace from 64-bit FF on windows: No misaligned accesses -- there's a reason why 32-bit windows is 15% slower than 64-bit on 64-bit machines...since you'd never seen the misaligned accesses before, perhaps you've been running either 64bit on 64 or 32 on 32-bit? To run 64-bit I have to go back to FF 3.6.3 -- the last version in the 3.6 series made available -- got taken to the welcome page on mozilla.org for fresh installs, where it promptly said I could 'upgrade' [sic], to a 32-bit 5.x version. Um, offering a 32-bit version as an upgrade to a 64-bit version is probably not a great idea... Stack: ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForMutexObject+0x19f ntoskrnl.exe!_misaligned_access+0xba4 ntoskrnl.exe!_misaligned_access+0x1821 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForMutexObject+0x19f win32k.sys!memset+0x7ac7 win32k.sys!memset+0x7b69 win32k.sys!W32pArgumentTable+0xa68a ntoskrnl.exe!KeSynchronizeExecution+0x3a43 USER32.dll!ZwUserWaitMessage+0xa xul.dll!gfxPDFSurface::operator=+0x27a23 xul.dll!gfxPDFSurface::operator=+0x273e1 xul.dll!gfxPDFSurface::operator=+0x276f8 xul.dll!NS_ShutdownXPCOM_P+0x2473 xul.dll!NS_DebugBreak_P+0x2794 xul.dll!gfxPDFSurface::operator=+0x27426 xul.dll!gfxPlatform::UpdateFontList+0x24217 xul.dll!XRE_main+0x13a3 firefox.exe+0x1404 firefox.exe+0x1590 firefox.exe+0x1790 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d Also, BTW, I just tried opening several windows simultaneously -- FF-64bit never went over 4-5% cpu usage. (24-30% of 1 core). Now if only 3.6.24 was in 64-bit...
lol welcome to my world... Mozilla really stuck their thumbs up their butts w/FF5.x and their new website design...
Big dog, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. Walsh, just so you know, Firefox x64 never got officially released. there are nightly versions of it, never any official x64 release
I apologize, Ty...I just didn't realize before I submitted my help request that nobody at Mozilla Support responds to Anything....EVER...but I know that's not your guys' responsibility, and I shouldn't discuss it here. :-)
Tyleer -- was unfortunately aware of the 64-bit support being for all platforms except windows...why is that? It's been available on linux for years, and is available on the Mac, but not windows. I don't need plugins as much as extension compatibility with 3.6.x -- everything you guys have done in the GUI in 4.0, 5.0 and are planning in future versions -- I already *can* have (and sometimes do, on a whim!), due to the extensions in 3.6.x I wish you guys hadn't been 'followers' and followed the google market in bumping up versions faster than makes any logical sense, but this is a market driven world, and if those in charge perceived value...well, so it was. Stable extension API's an large numbers of extensions are my primary reason for using FF -- take those away, might as well use Chrome. I really whish you'd put the 4.x and 5.x improvements in a 3.7 and/or 3.8...that could have remained (possibly) with more compat for existing extensions. I'd even, if I was a designer, choose 'namespaces' like the DTD defs at the top of HTML docs, to describe the feature set I want to use. Then the same binary could support extensions from multiple versions. Make each thunking layer a .so/.dll, that an be loaded as needed at runtime. Then you get best of all worlds. Anyway, I installed the x64 to demonstrate what a proper stack looks like on a 64-bit machine -- but the "corrupt" looking stack (as it was described by someone else), is the normal way FF-32 bit looks.
Walsh, you do realize that if an extension is not labeled compatible for anything over 3.6 is will break even if the next version is 3.8? you can always disable compatibility checking, or encourage your addon developers to update their extensions. Now AMO is working automatically updating extensions to make them marked compatible with future releases, but that is beyond what this bug is even about, as is the 64 bit issue. please, keep this bug on focus.
True, I I just installed the x64 version to see what the stack looked like. It is installed using the same profile as the x86 version, so has the same extensions. A fresh instance of firefox: Only 2 misaligns (been three on every other check...)...it's a 'feature' of win32-ff - that was my point -- not that it's a sign of a some other problem. ntoskrnl.exe!memset+0x64a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!__misaligned_access+0xba4 ntoskrnl.exe!__misaligned_access+0x1821 ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d ntoskrnl.exe!KeWaitForSingleObject+0x19f win32k.sys!memset+0x7ac7 win32k.sys!memset+0x7b69 win32k.sys!W32pArgumentTable+0xa68a ntoskrnl.exe!KeSynchronizeExecution+0x3a43 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x676 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!LdrpInitializeProcess+0x17e4 ntdll.dll!??_C@_0BN@KLOBBEB@Enabling?5heap?5debug?5options?6?$AA@FNODOBFM@+0x29220 ntdll.dll!LdrInitializeThunk+0xe USER32.dll!WaitMessage+0x15 xul.dll!?GetUnderlineOffset@gfxWindowsFontGroup@@UAENXZ+0x97a0 USER32.dll!UnhookWinEvent+0x1b4
I cannot tell if you are trying to report what the title of the bug says or that Firefox hangs. If the later, then this bug should be closed and you should file a new issue. Looking at the stacks, it's not clear what's going on. If you can't reproduce it on 5.0, I honestly wouldn't expect it to be fixed. I'll address a few things but most of the discussion seems to have been off-topic (like the version numbering change and extension compatibility challenges). You won't see each window's JS running in its own thread until well into the electrolysis project. It's an inherently huge design flaw in the browser that has been taken years to come up with a viable solution for. Extensions are actually part of the problem. Firefox 4+ splits some tasks (like HTML parsing) out into their own thread. You still haven't checked for me if the process or set of threads is being limited to a single core by some 3rd party. Besides using the task manager's process view (confusingly enough, right click on a process and select "set affinity"), another way to check is to go to the performance tab and see if only one core is being hit. Windows' scheduler likes to use all cores roughly evenly so if there's an artificial affinity being set, then it should be clear from these graphs. A third but unlikely possibility is that someone is setting an affinity on each thread that's created. I don't know of a good way to detect this. The reason 64 bit Windows builds aren't built/distributed (yet - it is coming) is primarily due to the lack of plugin support. 32 bit plugins don't work with 64 bit Firefox and 64 bit plugins aren't made because no one on Windows uses a 64 bit browser (even IE defaults to 32 bits). This is important for a number of users, but seemingly not you. The speedup you see is likely due to the architecture differences between x86 and x86-64.
There is no multi-core flag for binaries as far as I'm aware. Note that not using more than 100% of a CPU's worth of CPU usage does not mean that Firefox isn't multithreaded. Firefox often uses threads to do long operations (usually IO) to avoid blocking the main thread. These threads typically block for a long time, wake up for a bit to post a message to another thread, and then go back to sleep. They do not show up very much on CPU profiles. It sounds like what you really want is the electrolysis project to happen so that one page cannot kill the responsiveness of the browser. I'm going to dupe this bug against that.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
You're welcome L A. ;-) Always happy to keep testers busy. ^_^ So I'm not quite caught up on all the stack tracing tools and such for providing useful bug-finding data for windows, but...it may not matter. I noticed in my [brief] time using 5.0.1 that it actually did climb above 25% usage, for the first time ever. That I've seen. I'm attempting to tax my 5.0 FF on my work machine to see if it does the same, but so far I haven't seen it above 25%. I'm not touching 5.0.1 with a 39-and-a-half foot pole...perhaps I'll wait til FF6 is released, which is supposedly not as far off as I previously thought...
Not a duplicate of electrolysis, since the whole problem was people wanted proof that multiply competing tabs didn't run on more than one core. I attached a new attachment that I used to duplicate the problem. You open multiple tabs each with an instance of the 'bad program', -- They are all demanding 100% cpu, but ff as a whole only uses 16% (1/6 cores) cpu. It DOESN'T use multiple processors or cores -- which was the point of the original bug filed over 4 years ago.. It's not like I have been 'impatient' but this bug has been buried for years, and now people are trying to dup it off to something other than what it is. Yes, it may required restructuring FF and fixing things that never should have been designed that way in the first place, but back during initial creation, muliple cpu machines weren't plentiful. It may be that it would be hard. 'I agree! But if it work had started 4 years ago, and done a bit at a time, I bet you it'd be done or close to it by now. I.e. saying it is hard as a reason to do nothing about it solves nothing.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
LAWalsh, do not reopen this bug. Engineers have already said that the only way to fix this (and many other similar problems) is with content processes, which is what this bug was dupped to. Your continued harassment in the bug will not make anything better.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
I just tested this with 4.0 on linux -- same problem Multiple tabs -- all competing for 100% cpu -- yet ff only using 1 out of 8 cpus. Changing version to 'trunk', and affected cpu's/archs to all/all.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Version: 3.6 Branch → Trunk
Sorry, I missed your comment....from the description, electrolysis project is about improving UI responsiveness when progs are causing a slowdown. That could be solved many different ways than by utilizing multiple cores. I.e. That's not about multi-core/multi-cpu usage. -- IT MIGHT be addressed that way, but from the project description, it's not _necessarily_ about that. If my understanding is wrong, then fine, I'll redup it. But the project description of that bug should be made more clear that it's about utilizing multi-cores -- which as a side effect, could improve UI responsiveness.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
Depends on: electrolysis
The same problem with FF 11, Win 7 x64. FF uses only 25% of CPU.
Oh that's just wonderful... I'm pretty sure this doesn't happen on linux. Maybe it's an artifact of the windows scheduler and using threads? Maybe it's another example of windows being fundamentally flawed?... Other progs with thread run on multi-cpu/cores, why not ff?
How can this be considered resolved!? I'd just like to say that if it was not for this "Bug" I would still be using Firefox. In fact I still test it from time to time during a new version roll-out to see if you guys got with the program! I switched to Chrome 2+ years ago for the simple fact that I am a power user and need a multi-threaded browser. If I open 10 tabs in firefox, and several of them are cpu intensive, the whole browser can hang, and may need to be killed if any one of those tabs locks up. I could have something important in tab A, and when tab B locks up, oh well, it's lost. It's unacceptable at this stage. In Chrome, under the same situation the guilty tab becomes unresponsive and can be closed with the 'X' leaving the other tabs (processes) unaffected. This separation of processing is becoming more and more critical as websites become more complex, competing for resources, with the potential of a bug or error. May I propose a solution, run each tab in it's own process, let the OS handle the rest... BTW This has nothing to do with the OS, it's a fundamental flaw of the application. This should be escalated from bug to fundamental software design flaw.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I just experienced this: Tab 1: https://www.youtube.com/watch?v=eYJhFvoNdJI Tab 2: http://underthepianostool.blogspot.com.es/2010/12/arthur-rubinstein-master-class-chopin.html On tab 2, Av Pag (scroll down). Before tab 2 scrolled, the audio of the tab 1 was interrupted. Mozilla please. My 4 cores for what? 3 are ROFLing while the other one dies. Full specs: Intel Core i5-480M, 4 GB RAM, Linux 3.2.0-27-generic-pae, Lubuntu 12.04 fully updated, Firefox 17.0 (Beta). Even I have AdBlock Plus. Without it could have been even worse. Making a conservative prediction, in 2 years from now, mainstream will be: phones with 4 cores, laptops with 8 cores, desktops with 16 cores, users spending 80% of their time on the web. Without multicore support, what will Firefox be in that scenario? A friendly browser for low-end phones, at most. Then Firefox and by extension Mozilla will become irrelevant for the web. Please Mozilla and Firefox team: Set up a realistic plan to fix this bug before 2015.
spec: win xp 32-bit, intel i5 Can't believe this problem still exists in 2012. Please fix it before the world ends! :)
Dear developing team. This issue prevents me to use Firefox even I would really like to continue to use it. I was using Firefox for years when I had single-core PC or notebooks. Since I got 4 core PC I had to switch to google chrome, just because of speed (and responsibility - it uses all my 4 cores) even it lack functionality that i was using in FF (tree style tab) and uses much more memory. For me this issue is most important and until it will be fixed the chrome will be better choice for me even with missing functionality and other drawbacks. I thing it is the same for many other power users - the ones that influence the others. Please fix this issue before all the users switch to google chrome.
All add my discontent to this as well. All 3 of my PC's from dual to quad core, as well as any PC repair I have done.
(In reply to cschuler from comment #43) > When I load it on my 6-core machine, *3* of the CPUs jump up to 30-50% > usage, and the animations all run smoothly. Firefox actually runs in a lot of threads, which is why it all balances across the cores, but there seems to be some global locking which prevents those independent thread from running concurrently.
Actually, I haven't read all of the commentary, but.. seems to me that the most common time this happens, for me, is if I go to a site, or have others loading in the background, and one, or more of them, run into a case of trying to load animated gifs. It might be the case with other large files, like flash, but I can't be sure. But, the GUI doesn't have anything to do with the problem, for me, its a case of, "Oops, I have a lot of animations to load, lets lock up entirely, until I get a "large" percentage of them loaded." This might "look" prettier, or something, since the page in question won't display, until all the elements are there, to be seen, but.. I would almost prefer the old days, or having "missing picture" markers where they hadn't loaded yet, rather than have some background tab lock up everything, for a long time, in the middle of trying to do somethings else. And.. It only gets worse, if I am, for example, looking through some place like, say, Renderosity.com, or the like, where I am also popping open background windows, for pictures I want a better look at later. Then, combine all that background loading, or large files, with a sudden page of animated gifs... and of boy does things go wrong...
Agreed with previous posters, this is larger than a bug, it's a long-standing fundamental software design flaw that has become corrosive to all other Firefox capabilities. 15 years ago NCSA Mosaic under SunOS was solid, snappy, and responsive to user input regardless if individual windows got bogged down. By contrast Firefox's current CPU and memory handling architecture behave in bottlenecked fashion reminiscent of Microsoft Windows 3.x multitasking and memory management. Even under a capable OS like Windows 7 64-bit, with enough tabs open Firefox will gasp and struggle along starved for CPU and memory despite system utilization of both at only around 15%. Developer energies spent on bells and whistles like skins and toolbar layouts seem to me like fussing over stateroom window trimmings as the ocean liner's lower engine room decks progressively fill with seawater. I'm sticking with Firefox now only because I have more confidence in Mozilla's privacy intentions than Google's. But that may change as month by month Firefox continues to be less practically usable as a browser due to regular browser-wide slowdowns, lockups, and crashes from single-tab implosions.
How difficult would it be to write instrumenting code (time +waiters) around any and all locks to find the bottle necks?
Five and a half years and this bug is still here. Oh my goodness... Steps to reproduce problem: Load a handful (10+) of any NYTimes news reports, FF will lag significantly, with continuous full load on only one thread (my CPU is 4 core 8 thread). FF 19.0.2 (and many versions before that) CPU E3-1245 V2 RAM 16GB OS Win7Pro 64-bit
@M_Compute Good news on this front appeared this week: https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/ From the reading, I figure that an stable, secure, multi-threaded Firefox could be released before 2016.
I agree with H.F in comment 46. But I do not think I can wait as long as it seems it will be for RUST and SERVO. I use Waterfox, a 64-bit build of FF, occasionally. It does seem to work faster, and it is more reliable, but as stated above, not all add-ons work with it(due to its' 64-bit nature), so I cannot fully switch to it. I have also used Ice Dragon, by Comodo, a build of 32-bit FF that is focused on security. It has better add-on support, but lacks the performance of a 64-bit build. After more than 5 years here, I do not expect this bug to be fixed. When my browser crashes one too many times, I will reluctantly switch to Chrome. Pick your battles, nothing's perfect. I did not pay for FF, so I don't expect the developers to care about my opinion anyway.
I was thinking about this problem and how I might go about dealing with it given the very inter-woven nature of the code. I'd work BACK from the data I want to protect the most, and then least... meaning, I'd go with the fact that ultimately, you only want 1 writer writing to the session database (that will be stored on disk) at 1 time. That's the "HAVE TO" as far as I can tell. So I'd start with putting locks around all accesses -- which won't have any contention, 'now', as it's all 1-active process (i.e. it's a change that can be folded into the current code with little or no impact (other than code growth) -- it shouldn't break anything during this phase. Now it may be naive (I really don't know alot about the internals of FF), but once those are in place, What would prevent you spawning/forking a new browser instance on every 'tab' that is opened (or if that is too many, then maybe with every 'new' site that is opened, or if they open a new & separate window -- whatever makes the most sense)? The fork would use copy-on-write so since each copy that's spun off would be fully initialized -- at least internally, the only thing that would need tidying would be duplicating some set of the resource forks on windows, cuz it doesn't have a native fork. Now hopefully, you could start having multiple windows open that should be relatively independent of each other -- I would say in the first incarnation, there might be some limitations on communication between separate instances -- but if they were based on a windowing environment, I wouldn't think there'd be too much inter-process contention FF would have to solve (in the short term) as far as the windowing environment. It seems the biggie is to focus on protecting the session space/dir so multiple readers can be using it and hopefully writers won't need to write to it that often, as that will be a contention point -- a bit like the "big kernel lock" that used to exist in early SMP versions of linux. Once you've gotten that basic framework -- which should be achievable in parallel with other ongoing development efforts (as in the single, active-cpu case, it's not really doing much), then you can move forward with splitting the big lock into smaller chunks. For things like the local disk cache (which I don't even use in my setup cuz I have a local squid proxy cache running on a machine with larger disk space -- and everything goes through that) .. which led me to thinking -- why not do the same for FF. I.e. have a 'baby squid' - a proxy process that talks to the cache, and the separate 'computer' or 'worker' instances would do all their disk caching through through that proxy -- that would solve the problem of multiple reader/writers wanting access to the disk cache at the same time. From there, could start coordinating a memory proxy that keeps a larger cache of memory and the worker instance threads would do their caching through that -- not ideally efficient, but another notch up the performance scale. From a memory caching proxy, it could move toward sharing memory to allow for higher performance transfers, it the cache manager would move toward being a process that maintains the integrity of the the cache, but for I/O, it could point at a specific file for a client to retrieve directly, or a specific memory range, it would, at first, copy, but later, might be able to use directly... It seems like the main problem right now is "where to start"... Even though it wouldn't be the most efficient coordination at first, -- ANY speedup would be welcomed by users. Over time, it seems that with increasing coordination and finer granularity on work performed, there'd be tons of improvement work that could be done in parallel with other tasks. But this way, I don't know if my proposal makes any sense, but it it does, it seems like it would allow ongoing and new development, while at the same time, allowing the codebase to move toward increasing parallelization. It has the benefit of not needing a major interruption of all devel work to go off on something that wouldn't appear to provide new functionality (just reduce lags and such -- stuff that users often don't appreciate as much -- but really get bugged if it doesn't happen in tangent with newer, ongoing work)... ??? Sorry if this is all way to primitive or basic to be of any use, but I wasn't sure where you were in the devel process and didn't know if this type of feedback would even be of any use?... but I thought about what would be needed to make this transition "doable" (not take too many resources, and not block ongoing future projects)... feel free to email if you have any questions you wanna toss around... I can't guarantee anything, but given the problem maybe any possibilities that might happen in the 'sooner' category might make it worth the bother...? Just throwing this out...hope it's of some use (hell of a way to do project design though... ;-))...
I remember having read some paper from a Firefox dev that said that Firefox didn't need multi-threading (or multi-processing) because it was already well-optimized and multi-threading won't save a lot. At that time, I blindly believed what this guy was saying, and I thought Firefox was slower on Linux at home than on Windows at work for some other mystic reasons. But today I tried Chromium. To see with my own eyes that there were no improvement, and oh boy I was so wrong... Chromium is like 4 times faster that Firefox (on my 4-core CPU)! I'm really really sad about that discovery for Firefox is truly my favorite browser. Please Firefox devs, do consider doing some multi-threading and/or multi-processing. In the meantime, I'll have to stick with Chromium and I don't like that, but I got no other choice, I can't afford a quad core at 4GHz each.
(In reply to romain.failliot from comment #53) > I remember having read some paper from a Firefox dev that said that Firefox > didn't need multi-threading (or multi-processing) because it was already > well-optimized and multi-threading won't save a lot. > At that time, I blindly believed what this guy was saying, and I thought > Firefox was slower on Linux at home than on Windows at work for some other > mystic reasons. Firefox uses threads en masse (that can spread across multiple CPUs), so your info is false (or at least outdated). Also, plugins run in their own process, and currently there is ongoing work to separate the UI and content into its own process (project electrolysis, short: e10s). Please note that this bug dates back to 2007, that was 6 years ago! If you have issues with Firefox, you can try safe-mode or resetting Firefox to rule out some bad influences (your profile might be broken, or you have badly behaving addons installed): https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems Make sure that all your software is up to date, this includes Firefox itself, any addons and plugins, as well as your operating system, graphics and other hardware drivers (yeah, they can affect Firefox performance, too). If you still have speed issues, and they are not hardware related (e.g. slow harddrive), file a new bug (with specific descriptions of what is slow, maybe comparing it to other browsers, too) – it's definitely not related to CPU usage, but most likely unresponsiveness of certain parts of the browser (because it has to do disk I/O on the main thread, but this is also in the process of being refined, so please try a Aurora or Nightly release first and see if it fixes your problem).
(In reply to Florian Bender from comment #54) > Firefox uses threads en masse (that can spread across multiple CPUs), so > your info is false (or at least outdated). Also, plugins run in their own > process, and currently there is ongoing work to separate the UI and content > into its own process (project electrolysis, short: e10s). That's good to know, thanks. > If you have issues with Firefox, you can try safe-mode or resetting Firefox > to rule out some bad influences (your profile might be broken, or you have > badly behaving addons installed): > https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems > Make sure that all your software is up to date, this includes Firefox > itself, any addons and plugins, as well as your operating system, graphics > and other hardware drivers (yeah, they can affect Firefox performance, too). I'm using ArchLinux, meaning I've got kinda the latest software possible on Linux (I'm using the radeon open source drivers which have pretty decent performances on video games so I don't think it could be the reason). I've got 4 or 5 plugins, including adblock plus (well known), Ctrl+Tab and New tab homepage (very tiny plugins). I've reset my profile two months ago, and I did it already 6 months before it. It's a bit better, but it's really not perfect and, moreover, I don't want to delete my profile every 6 months! > If you still have speed issues, and they are not hardware related (e.g. slow > harddrive), file a new bug (with specific descriptions of what is slow, > maybe comparing it to other browsers, too) – it's definitely not related to > CPU usage, but most likely unresponsiveness of certain parts of the browser > (because it has to do disk I/O on the main thread, but this is also in the > process of being refined, so please try a Aurora or Nightly release first > and see if it fixes your problem). And here is the problem... There is no real steps to reproduce, no site to go to and "see for yourself"... As the time goes, Firefox just goes... slow. And the more you use it, the more it's slow (and plugins aren't the problem). And it is no only since few months, it's slow for the past 5 years! Of course, when you just open one page from time to time, there is no problem, but that's not my case: I have between 10 to 30 tabs opened, and I save my session. Because I don't want just to complain in this message, here is a suggestion: why not integrate a profile system directly in Firefox, so that we could really see what's going on?
This is not the right forum to discuss this. Please don't answer my comment, instead direct them to the mailing lists (e.g. firefox-dev [https://mail.mozilla.org/listinfo/firefox-dev] or mozilla.dev.platform). (In reply to romain.failliot from comment #55) > I'm using ArchLinux, meaning I've got kinda the latest software possible on > Linux (I'm using the radeon open source drivers which have pretty decent > performances on video games so I don't think it could be the reason). Theoretically, they may be blacklisted in Firefox due to security issues, check out about:support to see if you run hardware acceleration. > I've got 4 or 5 plugins, including adblock plus (well known), Ctrl+Tab and > New tab homepage (very tiny plugins). I've reset my profile two months ago, > and I did it already 6 months before it. It's a bit better, but it's really > not perfect and, moreover, I don't want to delete my profile every 6 months! Newer versions of Firefox restore most profile data (except addons and preferences). Either way, your profile does not seem to be the culprit here. A wild guess could be Bug 934934. > And here is the problem... There is no real steps to reproduce, no site to > go to and "see for yourself"... As the time goes, Firefox just goes... slow. Assuming it's not one of your addons, again, it sounds like Bug 934934 (so your sessionrestore file gets rather big which slows down Fx). > Because I don't want just to complain in this message, here is a suggestion: > why not integrate a profile system directly in Firefox, so that we could > really see what's going on? There is a profiler available which you can use: https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler Either way, it's definitely not this bug, so please open a new bug (you can start with "gets slower over a long time period" and add your usage pattern, and later refine the bug with newer findings).
http://www.shadertoy.com This page. Just this one bloody page, is a direct indictment of the failure to include multithreading. It literally ***will not load*** at anything like a sane time span, if at all, with Firefox. With something like Chrome, it loads quickly, and simply, without the slightest hint of slowing down. If there is anyone, for one moment, than things this isn't something that needs to be fixed... they just need to try to visit the above page with Firefox.
Or, since someone above claims it can thread, and across multiple CPUs, then... something else is horribly wrong. Because... the issue is symptomatic, I think, of why any number of pages may be slower than they should, and some things just go really seriously wrong (with another one being handling of things like "progressive display" of pages, like on Tumblr, and others).
(In reply to Florian Bender from comment #56) > This is not the right forum to discuss this. Please don't answer my comment, > instead direct them to the mailing lists (e.g. firefox-dev > [https://mail.mozilla.org/listinfo/firefox-dev] or mozilla.dev.platform). Applies here as well. Don't comment on bugs unless you provide any additional information to that particular bug. (In reply to Patrick Elliott from comment #57) > http://www.shadertoy.com Loads wonderfully fast on my Mac (MBA '12, takes about 2-3s, Chrome isn't any faster). Please file a new bug for this site with a description of your system & setup. > This page. Just this one bloody page, is a direct indictment of the failure > to include multithreading. It literally ***will not load*** at anything like > a sane time span, if at all, with Firefox. With something like Chrome, it > loads quickly, and simply, without the slightest hint of slowing down. If > there is anyone, for one moment, than things this isn't something that needs > to be fixed... they just need to try to visit the above page with Firefox. This is not due to multiple processes or something but due to other factors. Again, works good on my machine. If you have problems with specific sites, please file bugs. Worst case is that it gets duplicated to another bug, and that's ok!
There seems to be a confusion between multi-threading and multi-process architecture. Multi-threading allows a process to have multiple parallel threads of execution, however, they may or may not be parallel in real-time. e.g. most OS will only do time-slicing for threads of the same process. Multi-processing involves more than one independent processes (that may communicate with IPC or filesystem) and may have multiple threads within each process. Chrome uses multi-processing architecture whereas, to my understanding, Firefox doesn't. In multi-threading the memory is shared so no need for IPC, which makes programming much simpler than multi-processing. However, multi-processing is the right way to utilize all cores of a multi-core processor or multi-processor computer, considering the design or most common OS'es.
FYI, for those who want to follow along, there's a new blog post up explaining the ongoing effort: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/ Please test & file bugs, and don't add your findings to this bug.
Per comment #14, comment #22, comment #24, comment #26, comment #29 (and probably a few others), I dupe this bug to the e10s project. The core of e10s is separating chrome and content into multiple processes which will solve what the original bug report was about (IIUC). Bugs similar to the testcases attached (`while(true)`) were also duped to e10s. Additionally, the initial bug report tried to cover several issues at once which lead to some confusion during investigation. Thus, I propose the following (to keep things nice and clean): If multi-threading does not work on your system (read: there is proof), and you have steps-to-reproduce (STR), please file new bug with a description of your system & setup and STR. Please make sure that you have installed the latest (supported) versions of Firefox (that is, 24ESR and 25, though 26 gets released next week – please also try with pre-release versions like Aurora and Nightly if your problem exists there), any addons and plugins, and your operating system and hardware drivers (especially graphics). Also, please test in safe mode and with a new (clean) profile (or reset it) to see if there is some addon breaking Firefox BEFORE filing a new bug. Keep in mind that some operating systems may restrict resource usage by processes from time to time, so it's vital that you provide clear STRs. If you experience issues with out-of-process plugins, please file a new, separate bug. Whenever you file a bug, please include detailed descriptions of what you did to investigate this bug, so others can follow and understand your steps. This will drastically improve investigation & fixing time. Thanks! (In reply to Florian Bender from comment #61) > FYI, for those who want to follow along, there's a new blog post up > explaining the ongoing effort: > http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/ > > Please test & file bugs, and don't add your findings to this bug.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: e10s
I totally agree with you Florian. I'll do my best to give feedbacks on this. (BTW i tried http://www.shadertoy.com and it crashed my entire system... I suppose this is more Linux's fault though)
You need to log in before you can comment on or make changes to this bug.