Last Comment Bug 820248 - New DMD: gfx surfaces memory created by gfxPlatform::CreateDrawTargetForBackend are not reported
: New DMD: gfx surfaces memory created by gfxPlatform::CreateDrawTargetForBacke...
Status: NEW
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: ARM Gonk (Firefox OS)
-- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Milan Sreckovic [:milan]
Depends on:
Blocks: DarkMatter
  Show dependency treegraph
Reported: 2012-12-10 20:38 PST by Justin Lebar (not reading bugmail)
Modified: 2016-06-26 09:13 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Justin Lebar (not reading bugmail) 2012-12-10 20:38:03 PST
In the gallery app process in B2G with the gallery app in the foreground (see attachment 690543 [details]), I see:

> Unreported: 28 blocks in block group 1 of 215
>  1,720,320 bytes (1,612,800 requested / 107,520 slop)
>  13.57% of the heap (13.57% cumulative);  30.72% of unreported (30.72% cumulative)
>  Allocated at
>        malloc /Users/jlebar/code/moz/ff-git/src/memory/build/replace_malloc.c:152 (0x4020b2ae
>        moz_malloc /Users/jlebar/code/moz/ff-git/src/memory/mozalloc/mozalloc.cpp:65 (0x40e5adf2
>        gfxImageSurface /Users/jlebar/code/moz/ff-git/src/gfx/thebes/gfxImageSurface.cpp:110 (0x419ae7b6
>        nsRefPtr<gfxASurface>::assign_with_AddRef(gfxASurface*) /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/nsAutoPtr.h:846 (0x419c3ac0
>        gfxPlatform::CreateDrawTargetForBackend(mozilla::gfx::BackendType, mozilla::gfx::IntSize const&, mozilla::gfx::SurfaceFormat) /Users/jlebar/code/moz/ff-git/src/gfx/thebes/gfxPlatform.cpp:721 (0x40c5766a
>        mozilla::RefPtr<mozilla::gfx::DrawTarget>::operator mozilla::gfx::DrawTarget*() const /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/RefPtr.h:137 (0x40c576c8
>        operator mozilla::TemporaryRef<mozilla::gfx::DrawTarget><mozilla::gfx::DrawTarget> /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/RefPtr.h:141 (0x40c6e50a
>        mozilla::RefPtr<mozilla::gfx::DrawTarget>::assign(mozilla::gfx::DrawTarget*) /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/RefPtr.h:145 (0x406a3e42
>        mozilla::dom::HTMLImageElementOrHTMLCanvasElementOrHTMLVideoElement::IsHTMLCanvasElement() const /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/dom/UnionTypes.h:307 (0x406a58aa
>        mozilla::dom::CanvasRenderingContext2DBinding::drawImage(JSContext*, JS::Handle<JSObject*>, mozilla::dom::CanvasRenderingContext2D*, unsigned int, JS::Value*) /Users/jlebar/code/moz/B2G/objdir-gecko/dom/bindings/CanvasRenderingContext2DBinding.cpp:1593 (0x40b9a1fe
>        mozilla::dom::CanvasRenderingContext2DBinding::genericMethod(JSContext*, unsigned int, JS::Value*) /Users/jlebar/code/moz/B2G/objdir-gecko/dom/bindings/CanvasRenderingContext2DBinding.cpp:3245 (0x40b9b2cc

See also bug 820132, another bug where (different, I think) gfxSurfaces are unreported.
Comment 1 User image Jet Villegas (:jet) 2014-07-28 15:05:35 PDT
Jonathan: Are you still in this neighborhood? Accurate accounting of DrawTarget buffers will really help regression tracking for MemShrink. Can you pick this one up?
Comment 2 User image Jet Villegas (:jet) 2014-08-13 09:33:28 PDT
Bas: can we get a moz2D API to return the size of the backend surfaces allocated?
Comment 3 User image Bas Schouten (:bas.schouten) 2014-08-13 18:41:23 PDT
(In reply to Jet Villegas (:jet) from comment #2)
> Bas: can we get a moz2D API to return the size of the backend surfaces
> allocated?

I discussed this Milan. My suggestion for an extension to Moz2D is an abstract MemoryReporter baseclass, that can be implemented and set on the Factory. That baseclass will receive callbacks then when allocations occur, for example:

enum Reason {

RAMAllocated(Reason aReason);

That would allow Gecko to easily track the different types of memory that we use, report them in different manners and possibly make other (for example cache) decisions based on the numbers. I can write that Moz2D patch if we can agree that's something that we want, and help with hooking this up.
Comment 4 User image Nicholas Nethercote [:njn] 2014-08-13 19:00:51 PDT
Sounds good to me. 

Also, this might be relevant:
Comment 5 User image Jonathan Watt [:jwatt] 2014-08-14 04:15:22 PDT
Hmm. We want to be able to attribute allocations to the Moz2D object that is holding on to the memory. This is necessary for about:memory to be able to report that thing X in nsIDocument Y is using Z amount of memory. Only being able to say "Moz2D allocated X amount of memory in this process" is a lot less useful.

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