Last Comment Bug 728846 - Fennec uses 20% of a 1GHz A9 CPU to flash text box cursor
: Fennec uses 20% of a 1GHz A9 CPU to flash text box cursor
Status: VERIFIED FIXED
[gfx]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: ARM Android
: P3 normal (vote)
: mozilla14
Assigned To: Joe Drew (not getting mail)
:
:
Mentors:
Depends on: land-maple
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-20 05:13 PST by Julian Seward [:jseward]
Modified: 2012-05-29 08:35 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified
verified
beta+


Attachments

Description Julian Seward [:jseward] 2012-02-20 05:13:57 PST
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%.
Comment 1 Julian Seward [:jseward] 2012-02-20 05:29:28 PST
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)
Comment 2 Julian Seward [:jseward] 2012-02-20 08:20:36 PST
Still happens with m-c of today.
Comment 3 Joe Drew (not getting mail) 2012-02-20 08:23:14 PST
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)
Comment 4 Julian Seward [:jseward] 2012-02-20 09:31:41 PST
Much better -- CPU utilisation is about 5 x lower (4ish % of a core instead of
20 ish %)
Comment 5 JP Rosevear [:jpr] 2012-03-08 07:45:38 PST
Sounds like this should just close when maple lands on m-c.
Comment 6 JP Rosevear [:jpr] 2012-03-18 05:23:55 PDT
Closing as per #5.
Comment 7 Cristian Nicolae (:xti) 2012-05-29 08:35:33 PDT
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

Note You need to log in before you can comment on or make changes to this bug.