Closed
Bug 728846
Opened 12 years ago
Closed 12 years ago
Fennec uses 20% of a 1GHz A9 CPU to flash text box cursor
Categories
(Core :: Graphics, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla14
People
(Reporter: jseward, Assigned: joe)
References
Details
(Whiteboard: [gfx])
m-c of 14 Feb, built -g -O, --enable-application=mobile/android (the new native UI, iiuc) running on a Motorola Xoom STR: start up, go to https://bugzilla.mozilla.org Watch cpu load in a shell w/ 'top -d 2 -s cpu -m 19' CPU load never goes below 8% for org.mozilla.fennec_sewardj. Hovers between 8% and 12%, average 10%. Since it's dual core that's 20% of one core, or somewhere above 100 MIPS at a conservative guess. Touch the page background, so the cursor stops flashing. CPU use for fennec falls basically to zero. Select box so cursor starts flashing -- CPU use back to around 10%.
Reporter | ||
Comment 1•12 years ago
|
||
I ran the experiment again, this time using a marginally hacked Valgrind that prints a stack snapshot ever million or so ARM/Thumb instructions. This gives approximately 40 samples per cursor-flash, with the following repeating pattern (w.r.t. the top frame in each sample): a handful of samples in misc and generally not very repeatable places, eg: (NOTE: these are not stack traces, they are one- line-per-sample points): at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) at 0x1DBDD518: ??? (in /dev/ashmem) at 0x2AED9580: pt_PostNotifies (ptsynch.c:124) at 0x5015AD0: ??? (InterpAsm-armv7-a.S:26944) at 0x29F14422: nsFrame::DisplayBorderBackgroundOutline(nsDisplayListBuilder*, nsDisplayListSet const&, bool) (nsFrame.cpp:1412) at 0x29E96980: nsRegion::SubRect(nsRegion::nsRectFast const&, nsRegion&, nsRegion&) const (BaseRect.h:309) at 0x29D931E4: nsTArray_base<nsTArrayDefaultAllocator>::GetAutoArray BufferUnsafe(unsigned int) const (nsTArray-inl.h:84) at 0x2A79AFC0: _cairo_tor_scan_converter_generate (cairo-tor-scan-converter.c:1967) followed by this, which is more or less the same each iteration, and which I presume is the bulk of the expense: at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48C6: fast_composite_over_8888_0565 (pixman-fast-path.c:851) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) at 0x2A7D48D0: fast_composite_over_8888_0565 (pixman-fast-path.c:852) at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) at 0x2A7DC4BE: fast_path_fill (pixman-fast-path.c:2154) The calls to fast_composite_over_8888_0565 come from one particular stack only (this IS a call stack): at 0x2A7D49D8: fast_composite_over_8888_0565 (pixman-fast-path.c:864) by 0x2A7B9FB7: _moz_pixman_image_composite32 (pixman.c:373) by 0x2A78277F: _clip_and_composite_boxes (cairo-image-surface.c:3002) by 0x2A783203: _cairo_image_surface_paint (cairo-image-surface.c:3299) by 0x2A79591D: _cairo_surface_paint (cairo-surface.c:2109) by 0x2A77D07B: _cairo_gstate_fill (cairo-gstate.c:1285) by 0x2A770141: _moz_cairo_fill_preserve (cairo.c:2459) by 0x2A7093EF: gfxContext::Fill() (gfxContext.cpp:329) by 0x2A7349F7: mozilla::layers::ThebesLayerBuffer::DrawBufferQuadrant (gfxContext*, mozilla::layers::ThebesLayerBuffer::XSide, mozilla::layers::ThebesLayerBuffer::YSide, float) (ThebesLayerBuffer.cpp:111) by 0x2A734A79: mozilla::layers::ThebesLayerBuffer::DrawBufferWithRotation (gfxContext*, float) (ThebesLayerBuffer.cpp:123) by 0x2A72B9CB: mozilla::layers::BasicThebesLayerBuffer::DrawTo(mozilla ::layers::ThebesLayer*, gfxContext*, float) (BasicLayers.cpp:818) by 0x2A72E567: mozilla::layers::BasicThebesLayer::PaintThebes(gfxContext*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) (BasicLayers.cpp:770) by 0x2A72F1DB: mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) (BasicLayers.cpp:1922) by 0x2A72F25F: mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) (BasicLayers.cpp:1937)
Reporter | ||
Comment 2•12 years ago
|
||
Still happens with m-c of today.
Assignee | ||
Comment 3•12 years ago
|
||
What happens on maple builds? http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-maple-android/ (Ignore the fact that clicking on things is tricky at best, rotating the screen doesn't work well, zooming is haphazard—all known issues that we're working on)
Reporter | ||
Comment 4•12 years ago
|
||
Much better -- CPU utilisation is about 5 x lower (4ish % of a core instead of 20 ish %)
Updated•12 years ago
|
Keywords: fennecnative-betablocker
Updated•12 years ago
|
blocking-fennec1.0: --- → beta+
Comment 5•12 years ago
|
||
Sounds like this should just close when maple lands on m-c.
Assignee: nobody → joe
Depends on: land-maple
Updated•12 years ago
|
Priority: -- → P3
Updated•12 years ago
|
Whiteboard: [gfx]
Comment 6•12 years ago
|
||
Closing as per #5.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Target Milestone: --- → mozilla14
Comment 7•12 years ago
|
||
Comment #4 is confirmed on the latest Nightly. Closing bug as verified fixed on: Firefox 15.0a1 (2012-05-29) Firefox 14.0a2 (2012-05-29) Device: Galaxy Nexus OS: Android 4.0.2
You need to log in
before you can comment on or make changes to this bug.
Description
•