728846 - Fennec uses 20% of a 1GHz A9 CPU to flash text box cursor

Status: VERIFIED FIXED

(Core :: Graphics, defect, P3)

Description

[Julian Seward [:jseward]]

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]]

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]]

Still happens with m-c of today.

Comment 3

[Joe Drew (not getting mail)]

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]]

Much better -- CPU utilisation is about 5 x lower (4ish % of a core instead of
20 ish %)

Comment 5

[JP Rosevear [:jpr]]

Sounds like this should just close when maple lands on m-c.

Comment 6

[JP Rosevear [:jpr]]

Closing as per #5.

Comment 7

[Cristian Nicolae (:xti)]

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