Closed
Bug 592321
Opened 14 years ago
Closed 13 years ago
firefox 4beta5candidate1 creates enormous system (likely gfx (directx?) layer related) load on winxp - huge contrast to beta4 (no such woes there)
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: abittner, Unassigned)
Details
(Whiteboard: [4b5])
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 maybe some deep internals have changed, but i just upgraded my previously pretty much normally behaving firefox 4 beta4 to the candidate build1 of beta5 (english winxp, x86, multicore cpu, some ati embedded graphics card (portable machine)) and now whenever i even do just as little as enter this text in this edit field while filing this bug, or simpy raise the firefox windows and hover/move the mouse over the firefox areas or scroll the window or surf some pages or do anything at all, firefox creates huge load (100% core load, aka a single thread creates 100% load arriving at 50% cpu load on dualcore machine) apparently in some drawing/display subroutines on this windows xp machine, while beta4 has not behaved like this. i think i recall some roadmap towards accelerated directx or similar stuff related rendering things the firefox team wanted to do, though im unsure if winxp/directx9 was also affected or being tackled by the roadmap and plans. but something has a severe impact on the winxp machine and its load, which is very most likely related to the displaying and drawing of things on screen. process explorer (sysinternals/msft tool) clearly shows firefox generating a very high percentatage of a red graph within its own load, so the green percentage (non-system load) is most of the time very low. having already followed the amd-code-analyst howto pages on https://developer.mozilla.org/Profiling_with_AMD_CodeAnalyst i tried to narrow down the problem with the beta5 build of firefox4, and codeanalyst reports the firefox.exe usage as follows: a very high hal.dll (55.75% during these 30second sample cycles of codeanalyst) usage (\windows\system32\hal.dll) second is xul.dll (total of 21.4% cycles) whose internal subroutine load samples dont really look revealing or suspicious to me and third and fourth place are the ati (graphics driver) components of this machine with 13.17% and 3.41% cpu cycles (ati2cpag.dll and ati2dvag.dll both is \windows\system32\) fifth position is mozcrt19.dll with 1.96% cpu cycles within the firefox.exe scope...... there has to be some serious changes in the firefox4 codebase which has been added or activated with the beta5 build, which at least makes firefox4 beta5 pretty much unusable on this ati-graphics card based machine. Reproducible: Always
something that i forgot: the hal.dll usage of firefox.exe process is almost completely being consumed by: ------ CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf54 HalpQueryPerformanceCounter 98.59 1 function, 12 instructions, Total: 8794 samples, 92.61% of samples in the module, 22.03% of total session samples -------------- and inside that routine apparently by: --------- CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf73 HalpQueryPerformanceCounter+31 97.85 1 function, 1 instruction, Total: 8728 samples, 91.91% of samples in the module, 21.87% of total session samples --------------------- maybe that helps. somebody forgot to turn off some performance counters or something? cheers.
|
||
Comment 2•14 years ago
|
||
abittner: Hardware accleration is on by default in this build - see https://wiki.mozilla.org/Platform/2010-08-31#GFX. What happens if you pref it off in your case?
odd thing is: that about:config says those two lines for layers/acceleration layers.accelerate-all;false layers.accelerate-none;false are both set to default boolean false. is this correct? sound like i dont have acceleration enabled at all, have i? what do i need to set?
are we going anywhere? i think i need to revert back to firefox4beta4 as beta5 is painstakingly slow and barely usable with this bug. i hope that im not the sole winxp/ati/ffx4b5 user experiencing this problem or rather wondering if there are other people experiencing this bug. regards.
|
|
||
Comment 5•14 years ago
|
||
abittner: So only Win7 and Vista are supported for hardware acceleration. If you type about:support and scroll down, you should see both Direct2DEnabled and DirectWrite set to false.
about:support direct2 shows as false. Graphics Adapter DescriptionATI Radeon Xpress Series Vendor ID1002Device ID5975Adapter RAMUnknownAdapter Driversati2dvagDriver Version8.591.0.0Driver Date2-25-2009Direct2D EnabledfalseDirectWrite Enabledfalse so why is this such a huge loss of responsiveness and such an increase of hal.dll workload? what has changed with beta5 regarding winxp? like i wrote before, my knowledge was that these directx/directd methods were only being considered and being added for vista and higher win operating systems. so why is there any impact at all on winxp? anyone seen any other related bugs to mine? i wonder if others find ffx4beta5 unusable on winxp similar to me. :( regards.
even with -safe-mode and selecting disable all addons firefox behaves like this all the time. hal.dll is running mad and generating 98%-99% CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf54 HalpQueryPerformanceCounter 98.45 1 function, 7 instructions, Total: 3611 samples, 86.97% of samples in the module, 18.09% of total session samples load......... (percentage inside hal.dll load) resulting in firefox roughly using 4x%-50% cpu on a dualcore machine, meaning this hal.dll load consuming a complete core for itself :((
reverted back to ffx4beta4 and doublechecked there: using this bugzilla bugreport website with this textbox/comments area as my benchmark.... typing some random text in here, and check-spelling activated for this textbox the beta4 results within firefox.exe load are as follows: Process Name 64-bit Timer samples xul.dll 66.09 MOZCRT19.dll 9.76 hal.dll 8.72 ntkrnlpa.exe 4.16 ntdll.dll 2.37 win32k.sys 2.14 nspr4.dll 1.91 ati2cqag.dll 1.1 USER32.dll 0.69 kernel32.dll 0.58 ati2dvag.dll 0.52 MSCTF.dll 0.46 GDI32.dll 0.35 --------- the percentage of the load being consumed for hal.dll functions is way lower than with beta5. something is wrong here. :(
I just updated to the "official" beta 5 on a WinXP machine and am seeing 90-100% CPU usage if I do anything at all in Firefox, including typing this comment. (I haven't done all the testing abittner has, other than checking about:config and about:support as mentioned above, and all are "false.") I agree - something is wrong. :(
|
Reporter | |
Comment 10•14 years ago
|
||
phew, thanks for that comment, i was already scared that i had some exotic system, drivers or system specs here that would leave me alone with this bug ;( the only system i had for testing this situation so far is some older business laptop from hp/compaq with integrated ati chipset, and the latest catalyst driver for winxp was the 10.2 catlyst, meaning february 2010 as a release date, and just as of very recently some days ago ati/amd hinted that they wouldnt be releasing any newer catlyst drivers any more for their older chipsets, although they had planned to do so before. well anyways, maybe its not even an ati/drivers problem as older firefox builds (even earlier ffx4 betas) worked just fine, ofcourse i understand that probably new drawing subsystems have been established and are being used, only i fail to understand why this would affect the winxp platform, as my understanding was that these new direct2d/direct3d things were only being activated in firefox4 for vista and higher windows operating systems using directx10 and so on...... i will try to find some other systems with winxp where i can mess around with ffx4 beta4/beta5 and try to verify there, but i have no eta/timeframe for that. thanks and regards.
|
|
Reporter | |
Comment 11•14 years ago
|
||
so i am here on a completely different machine using windows xp as well and using firefox 4 beta4 build for starters, later comparing beta5 results.... the above text was just my benchmark inside this comment window .... on this other machine i found. system: windows xp professional, sp3, x86, firefox 3.6.x so far, longterm usage of firefox (profile wise). added firefox 4 beta4 as an additional browser. started up firefox4 beta4 and now i am here. hardware is embedded (onboard, desktop machine) ati chipset, ati radeon hd 4200 / rs880 / 785G onboard integrade gpu chipset latest (august 2010, radeon catalyst 10.8 drivers package being used). the amd code analyst results for beta4 (typing in this comments box) for starters: whole firefox.exe process load on this quad/4 core machine: Process Name 64-bit Timer samples firefox.exe 2.46 load within firefox.exe process: Process Name 64-bit Timer samples xul.dll 63.8 MOZCRT19.dll 8.9 hal.dll 5.8 ntkrnlpa.exe 5.64 win32k.sys 4.68 ntdll.dll 3.41 nspr4.dll 1.83 USER32.dll 1.37 kernel32.dll 0.86 ati2dvag.dll 0.71 ati2cqag.dll 0.66 ------- hal.dll has fairly low percentage, xul.dll is largest. will test beta5 after this.
|
|
Reporter | |
Comment 12•14 years ago
|
||
beta5: firefox4 beta5 results are not as bad as on the other machine (business laptop) here on this one, still the whole firefox gui/ui feels somehow still a bit more lagging, less responsive and dragging, even on this much newer chipset/machine and twice as much cores. so take the cpu and load percentages with a grain of salt, maybe multiplying by factor two isnt just enough or an aproach too simple and results might probably not be that comparable. also ofcourse the whole ati/amd driver is much newer and most current, whereas the driver for the business laptop chipset is way older. typing in this comment textbox (spellchecking turned off) benchmark: Process Name 64-bit Timer samples firefox.exe 3.49 within firefox.exe process: Process Name 64-bit Timer samples xul.dll 61.56 hal.dll 16.89 MOZCRT19.dll 6.42 win32k.sys 3.84 ntkrnlpa.exe 3.26 ntdll.dll 3.05 nspr4.dll 1.11 ati2dvag.dll 0.68 ati2cqag.dll 0.61 ------- so hal.dll still accounts for almost 17% cpu usage (remember the 4 cores on this machine). inside hal.dll: CS:EIP Symbol + Offset 64-bit Timer samples 0x806ecf73 HalpQueryPerformanceCounter+31 87.05 0x806ecf58 HalpQueryPerformanceCounter+4 0.42 0x806ecf5e HalpQueryPerformanceCounter+10 0.42 0x806ecf79 HalpQueryPerformanceCounter+37 0.42 0x806ecf83 HalpQueryPerformanceCounter+47 0.21 0x806ecf85 HalpQueryPerformanceCounter+49 0.21 0x806ecf8c HalpQueryPerformanceCounter+56 0.21 0x806ecf93 HalpQueryPerformanceCounter+63 0.21 0x806ecf95 HalpQueryPerformanceCounter+65 0.21 0x806ecf54 HalpQueryPerformanceCounter 89.38 0x806e6aa8 KeReleaseQueuedSpinLock 3.61 0x806e69f0 KeAcquireInStackQueuedSpinLock 2.12 3 functions, 16 instructions, Total: 448 samples, 60.79% of samples in the module, 0.56% of total session samples inside xul.dll: CS:EIP Symbol + Offset 64-bit Timer samples 0x101d8840 mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 7.34 0x101a7930 XPCConvert::NativeInterface2JSObject 4.78 0x101d5c30 nsIFrame::BuildDisplayListForChild 3.49 0x101bce90 js::Interpret 2.85 0x101daf40 SearchTable 2.68 0x10130c80 write_string 1.81 0x101d6cb0 nsBoxFrame::BuildDisplayList 1.75 7 functions, 237 instructions, Total: 424 samples, 24.69% of samples in the module, 0.53% of total session samples -------- about:support on this quadcore ati radeon hd4200 machine: gfx section: Graphics Adapter Description ATI Radeon HD 4200 Vendor ID1002 Device ID9710 Adapter RAM Unknown Adapter Drivers ati2dvag Driver Version 8.762.0.0 Driver Date 8-3-2010 Direct2D Enabled false DirectWrite Enabled false ------------- i would really like to know what happend in terms of drawing the actual pixels or organising the layers elements and objects of the webpages in between the beta4 and beta5 build. there must have been some severe changes other than that i cant come up with any idea why beta5 would behave so laggy and sluggish in contrast to beta4. will try some grafx-bot benchmark stuff later on on both machines and both beta versions https://addons.mozilla.org/en-US/firefox/addon/200733/
|
|
Reporter | |
Comment 13•14 years ago
|
||
once more for doublecheck. on the newer winxp/atihd4200 machine, with firefox4 beta4, typing in this comments box, spellcheck off: firefox complete process load: Process Name 64-bit Timer samples firefox.exe 1.84 within firefox.exe: Process Name 64-bit Timer samples xul.dll 69.61 MOZCRT19.dll 8.5 win32k.sys 5.03 ntkrnlpa.exe 4.89 ntdll.dll 3.74 hal.dll 1.9 nspr4.dll 1.43 USER32.dll 1.22 kernel32.dll 0.82 ati2cqag.dll 0.48 GDI32.dll 0.48 very low hal.dll load all the times, have tried to bench this repeatedly. hal.dll load is always low/normal. --- Application Basics Name Firefox Version 4.0b4 Graphics Direct2D Enabled false ----
|
|
Reporter | |
Comment 14•14 years ago
|
||
maybe some more hints. the faser hd4200 based machine: grafx-bot results: beta4: http://brasstacks.mozilla.com/resultserv/data/results/fc145ac8-4613-43c2-9f7c-6c41bd1ece57 beta5: http://brasstacks.mozilla.com/resultserv/data/results/3930325c-9901-4002-964b-0b04885fc544 more tests fail in beta5 than in beta4. beta4 finishes the grafx bot tests a whole lot quicker than beta5.
|
|
Reporter | |
Comment 15•14 years ago
|
||
on the other slower machine (hp compaq business laptop), grafx-bot results: beta4: (almost all tests pass, except for one) http://brasstacks.mozilla.com/resultserv/data/results/20e275b2-3df4-4e5d-8172-599276994965 beta5: (more tests fail here) http://brasstacks.mozilla.com/resultserv/data/results/f0779ce5-c928-452f-bfa0-81434cc0e49c
|
|
Reporter | |
Comment 16•14 years ago
|
||
update with more recent firefox 4 beta7 pre (minefield) builds. have been using beta7 pre builds for the past one or two weeks in addition to the release betaX builds of firefox 4. this bug behaviour changes almost daily in the b7pre builds. some daily builds are really fast, lowlatency and well behaving, others feature sometimes almost constant 50% cpu (aka 1full core) loads on a dualcore machine. for example with build: Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100926 Firefox/4.0b7pre its really bad today. minefiled (firefox.exe) is really lagging a lot: amd codeanalyst displays again large hal.dll load and xul load. hal.dll load: CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf54 HalpQueryPerformanceCounter 97.05 1 function, 10 instructions, Total: 2531 samples, 88.68% of samples in the module, 12.68% of total session samples ----- xul.dll load: exibits mainly various javascript related(?) load: CS:EIP Symbol + Offset 64-bit Timer samples 0x1023da60 JSCompartment::purge 8.08 0x101b4dc0 mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 4.78 0x1019dd80 JS_TraceChildren 3.99 0x1023d850 JSC::RepatchBuffer::relink 3.29 0x102eee40 js::PurgeScriptFragments 3.03 0x101b7490 PL_DHashTableOperate 2.55 0x101b3bc0 nsIFrame::BuildDisplayListForChild 2.5 0x1023da10 js::Vector<JSC::ExecutablePool *,0,js::SystemAllocPolicy>::end 2.34 0x10169aa0 nsPresContext::GetRootPresContext 1.91 0x102eed30 js_DestroyScript 1.75 0x101b7720 SearchTable 1.59 0x1023d8f0 js::mjit::ic::PurgePICs 1.54 0x1019d8b0 fun_trace 1.38 0x101b3b10 nsStyleContext::DoGetStyleDisplay 1.38 0x1023d870 GetPropCompiler::reset 1.28 0x101b3ac0 nsRuleNode::GetStyleDisplay 1.22 0x101ae220 nsBoxFrame::BuildDisplayList 1.17 0x1023d970 js::mjit::ic::PICInfo::reset 1.06 18 functions, 279 instructions, Total: 844 samples, 44.85% of samples in the module, 4.23% of total session samples ------------ :(( anyone care for this bug? why is the hal.dll stuff so flaky, one day the build suffers from huge hal.dll load, the next day the following build is back to virtually normal behaviour. the javascript stuff might be related to some other code areas and bugs i guess and not necessarily directly related maybe this https://bugzilla.mozilla.org/show_bug.cgi?id=579653 and https://bugzilla.mozilla.org/show_bug.cgi?id=570435 ..... cheers.
|
|
Reporter | |
Comment 17•14 years ago
|
||
summing up the past few days worth of nightlies of beta7pre: every day a new/different situation. one nightly is pretty nice, reactive, doesnt show this hal.dll load problem too much, the next day the following nightly build is all messy again, huge hal.dll/halpqueryperformancecounter load once again. its really hard this way and i just havent found any place on the web or on the vast amount of mozilla pages blogs and development areas to be able to find out about these directx/layer/d3d/d2d and whatnoth features, and i still generally fail to understand why we/i actually see any problems using a windowsxp operating system, because so far any reliable information i found, was stating that nothing changes for winxp users (which simply cannot be true according to my experience and findings, this is obvious by now) but only for vista/win7/directx10+ users upwards. so todays build: Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre Source Built from http://hg.mozilla.org/mozilla-central/rev/dee1e01fd8ed is one of the slower daily builds of the recent week or so, not the worst/slowest though, and i dont have any of the recently experienced mozalloc.dll crashes (sadly unhandled by breakpad/crashreporter :((( ) as i posted in my other bug at https://bugzilla.mozilla.org/show_bug.cgi?id=600481 i re-started with multiple windows tabs and tabcandy/panorama and waited a while to find a somewhat idle state of the firefox.exe process and measured with amd-codeanalst: idle firefox (on avarage still using 11%cpu) Process Name 64-bit Timer samples firefox.exe 11.18 within firefox.exe: Process Name 64-bit Timer samples xul.dll 36.99 hal.dll 30.28 mozjs.dll 16.23 MOZCRT19.dll 5.56 win32k.sys 2.6 ntdll.dll 2.02 ntkrnlpa.exe 1.66 ati2cqag.dll 1.55 nspr4.dll 0.58 ati2dvag.dll 0.4 there you can see some hal.dll load already. xul.dll load: CS:EIP Symbol + Offset 64-bit Timer samples 0x1005e000 PresShell::DidPaint 7.88 0x100b2690 PL_DHashTableOperate 6.36 0x1007f110 nsViewManager::DispatchEvent 5.94 0x100b2bb0 mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 5.03 0x100ba8e0 nsBoxFrame::BuildDisplayList 4 0x100b58b0 nsIFrame::BuildDisplayListForChild 2.85 0x100b2530 mozilla::FramePropertyTable::Get 2.48 0x100b25a0 SearchTable 2.24 0x101f5e60 GraphWalker<scanVisitor>::DoWalk 2.24 0x10116e60 nsViewManager::ProcessPendingUpdates 1.76 0x100f6f20 ChangeTable 1.64 0x100b6df0 nsRuleNode::GetStyleDisplay 1.58 0x100b72f0 NoteJSChild 1.33 0x100b6dc0 nsStyleContext::DoGetStyleDisplay 1.21 0x1009a0f0 nsXPConnect::Traverse 1.09 15 functions, 285 instructions, Total: 786 samples, 47.64% of samples in the module, 1.97% of total session samples -------- hal.dll load: CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf54 HalpQueryPerformanceCounter 95.78 0x806e5ad0 HalpReleaseSystemHardwareSpinLock 1.78 0x806e79f0 KeAcquireInStackQueuedSpinLock 0.89 3 functions, 13 instructions, Total: 1330 samples, 66.27% of samples in the module, 3.33% of total session samples ---- halpqueryperformance counter as usual behaving badly: CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf73 HalpQueryPerformanceCounter+31 94.52 0x806edf93 HalpQueryPerformanceCounter+63 0.44 0x806edf54 HalpQueryPerformanceCounter+0 0.15 0x806edf55 HalpQueryPerformanceCounter+1 0.15 0x806edf79 HalpQueryPerformanceCounter+37 0.15 0x806edf88 HalpQueryPerformanceCounter+52 0.15 0x806edf6c HalpQueryPerformanceCounter+24 0.07 0x806edf7f HalpQueryPerformanceCounter+43 0.07 0x806edf83 HalpQueryPerformanceCounter+47 0.07 0x806edf54 HalpQueryPerformanceCounter 95.78 1 function, 9 instructions, Total: 1294 samples, 64.47% of samples in the module, 3.24% of total session samples ---------- so after that i wanted to see if firefox.exe would eat up a whole core again when being nagged a bit of input. so i created one new tab (empty), and simply started to move about the mouse a bit, and all of a sudden firefox.exe went lunatic: Process Name 64-bit Timer samples firefox.exe 45.71 System Idle 40.18 System 4.95 ---- Process Name 64-bit Timer samples hal.dll 47.71 ati2dvag.dll 15.85 xul.dll 11.05 ntkrnlpa.exe 10.61 ati2cqag.dll 8.94 MOZCRT19.dll 1.93 win32k.sys 1.57 ntdll.dll 0.47 ---- CS:EIP Symbol + Offset 64-bit Timer samples 0x806edf54 HalpQueryPerformanceCounter 93.73 0x806e7fb0 HalpPmTimerStallExecProc 3.32 0x806e5ad0 HalpReleaseSystemHardwareSpinLock 1.41 0x806e79f0 KeAcquireInStackQueuedSpinLock 0.44 4 functions, 21 instructions, Total: 8611 samples, 90.86% of samples in the module, 21.57% of total session samples -------- interesting xul.dll load as well: CS:EIP Symbol + Offset 64-bit Timer samples 0x1007f110 nsViewManager::DispatchEvent 8.48 0x1005e000 PresShell::DidPaint 8.38 0x100b2bb0 mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 7.19 0x100ba8e0 nsBoxFrame::BuildDisplayList 4.16 0x100b58b0 nsIFrame::BuildDisplayListForChild 4.02 0x100b2530 mozilla::FramePropertyTable::Get 2.68 0x100b6dc0 nsStyleContext::DoGetStyleDisplay 1.88 0x100b6df0 nsRuleNode::GetStyleDisplay 1.88 0x100b25a0 SearchTable 1.74 0x100b2690 PL_DHashTableOperate 1.24 0x100c5630 nsTHashtable<nsPtrHashKey<nsIFrame> >::s_EnumStub 0.94 0x100aab10 nsTArray_base::EnsureCapacity 0.89 0x100ba4d0 nsIFrame::GetUsedBorder 0.89 0x100bb7d0 mozilla::FrameLayerBuilder::DrawThebesLayer 0.89 0x100d9800 nsBlockFrame::InvalidateInternal 0.79 0x100b9680 nsRegion::SubRect 0.69 0x100b8a50 nsRegion::SetToElements 0.64 0x100cfd80 nsIFrame::GetOffsetToCrossDoc 0.59 0x100d3f50 nsRuleNode::WalkRuleTree 0.59 0x1034f54a mozilla::FrameLayerBuilder::Clip::Clip 0.59 0x100b84d0 nsDisplayList::ComputeVisibilityForSublist 0.55 0x100b8b10 nsRegion::And 0.55 22 functions, 410 instructions, Total: 1014 samples, 50.27% of samples in the module, 2.54% of total session samples ----------- another sampling attempt, while firefox was still going crazy for many minutes: Process Name 64-bit Timer samples firefox.exe 46.3 System Idle 39.34 System 5.27 ---- Process Name 64-bit Timer samples hal.dll 38.02 xul.dll 15.42 ati2dvag.dll 14.2 ntkrnlpa.exe 10.37 ati2cqag.dll 7.37 mozjs.dll 7.01 MOZCRT19.dll 2.91 win32k.sys 1.53 ntdll.dll 0.75 nspr4.dll 0.33 ----- xul.dll load: CS:EIP Symbol + Offset 64-bit Timer samples 0x1007f110 nsViewManager::DispatchEvent 5.04 0x1005e000 PresShell::DidPaint 4.66 0x100ba8e0 nsBoxFrame::BuildDisplayList 3.99 0x100b2690 PL_DHashTableOperate 3.96 0x100b2bb0 mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 3.92 0x100b58b0 nsIFrame::BuildDisplayListForChild 2.42 0x100b25a0 SearchTable 1.54 0x100b2530 mozilla::FramePropertyTable::Get 1.51 0x101f5e60 GraphWalker<scanVisitor>::DoWalk 1.4 0x100b6df0 nsRuleNode::GetStyleDisplay 1.26 0x100b72f0 NoteJSChild 1.19 0x100b6dc0 nsStyleContext::DoGetStyleDisplay 1.02 0x100a3530 XPC_WN_GetterSetter 0.95 0x100f6f20 ChangeTable 0.84 0x100a7060 nsXPCWrappedJSClass::CallMethod 0.81 0x100cfd80 nsIFrame::GetOffsetToCrossDoc 0.74 0x100a21e0 XPCConvert::NativeInterface2JSObject 0.7 17 functions, 386 instructions, Total: 1026 samples, 35.91% of samples in the module, 2.56% of total session samples
|
||
Updated•13 years ago
|
Version: unspecified → Trunk
|
|
||
Comment 18•13 years ago
|
||
Reporter -> Are you still experiencing this issue with the latest version of Firefox 5? Does the issue occur with the latest nightly? http://nightly.mozilla.org/
|
|
||
Comment 19•13 years ago
|
||
Closing bug as Incomplete - if you are still experiencing this issue or have more information to provide feel free to post back here and we can re-open the bug. You can also get assistance by visiting the Firefox help site -> http://support.mozilla.com/en-US/kb/Ask+a+question
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•