Last Comment Bug 756767 - [Azure] Reduce memory peaks due to surface creation
: [Azure] Reduce memory peaks due to surface creation
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal (vote)
: mozilla15
Assigned To: Bas Schouten (:bas.schouten)
:
Mentors:
Depends on:
Blocks: 715768
  Show dependency treegraph
 
Reported: 2012-05-19 05:16 PDT by Bas Schouten (:bas.schouten)
Modified: 2012-05-23 08:11 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support. (19.01 KB, patch)
2012-05-19 06:04 PDT, Bas Schouten (:bas.schouten)
no flags Details | Diff | Review
Part 2: Deal with CreateSourceSurfaceFromData failing. (5.14 KB, patch)
2012-05-19 06:05 PDT, Bas Schouten (:bas.schouten)
jmuizelaar: review+
Details | Diff | Review
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support. v2 (24.41 KB, patch)
2012-05-19 08:59 PDT, Bas Schouten (:bas.schouten)
jmuizelaar: review+
Details | Diff | Review
Part 2: Deal with CreateSourceSurfaceFromData failing. v2 (10.88 KB, patch)
2012-05-21 08:12 PDT, Bas Schouten (:bas.schouten)
jmuizelaar: review+
Details | Diff | Review

Description Bas Schouten (:bas.schouten) 2012-05-19 05:16:36 PDT
https://tbpl.mozilla.org/php/getParsedLog.php?id=11879221&tree=Try&full=1 shows a problem in our current Azure-Thebes wrapper implementation. When it's trying to draw a very large surface a memory spike exists, this is because for the 10Kx10K surface, a SourceSurfaceD2D is created by gfxPlatform::GetSourceSurfaceForSurface. Since it cannot create a Texture for this size it will copy the memory into an internal storage. Doubling the 10Kx10Kx4 memory usage. SourceSurfaceD2D creation should just fail for these large surface, and a SourceSurfaceData should be introduced that can 'wrap' existing memory without making a copy. DrawTargetD2D should then be adjusted to be able to deal with SourceSurfaceData.

This has two advantages:
- Not making a copy will reduce memory usage
- DrawTargetD2D will then have support for any DataSourceSurface (as it can support SourceSurfaceData through the DataSourceSurface interface)
Comment 1 Bas Schouten (:bas.schouten) 2012-05-19 06:04:32 PDT
Created attachment 625401 [details] [diff] [review]
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support.
Comment 2 Bas Schouten (:bas.schouten) 2012-05-19 06:05:07 PDT
Created attachment 625402 [details] [diff] [review]
Part 2: Deal with CreateSourceSurfaceFromData failing.
Comment 3 Bas Schouten (:bas.schouten) 2012-05-19 08:59:25 PDT
Created attachment 625413 [details] [diff] [review]
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support. v2

Add files missing in first patch.
Comment 4 Bas Schouten (:bas.schouten) 2012-05-19 09:00:19 PDT
It does block enabling by default, as it causes occasional OOM on a reftest on Tryserver.
Comment 5 Jeff Muizelaar [:jrmuizel] 2012-05-21 07:15:06 PDT
Comment on attachment 625413 [details] [diff] [review]
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support. v2

Review of attachment 625413 [details] [diff] [review]:
-----------------------------------------------------------------

This looks decent. My biggest issue is the naming, but even that's probably not a show stopper.

::: gfx/2d/SourceSurfaceData.h
@@ +42,5 @@
> +
> +namespace mozilla {
> +namespace gfx {
> +
> +class SourceSurfaceData : public DataSourceSurface

Having SourceSurfaceData and DataSourceSurface is not good naming. Can we come up with something better than just reordering the words?

::: gfx/2d/Tools.h
@@ +83,5 @@
>  {
>    return hypotf(aB.x - aA.x, aB.y - aA.y);
>  }
>  
> +static inline int BytesPerPixel(SurfaceFormat aFormat)

This should probalby have 'static inline int' above to be consistent with Distance()
Comment 6 Jeff Muizelaar [:jrmuizel] 2012-05-21 07:18:33 PDT
Comment on attachment 625402 [details] [diff] [review]
Part 2: Deal with CreateSourceSurfaceFromData failing.

Review of attachment 625402 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxPlatform.h
@@ +199,5 @@
> +    /*
> +     * Creates a SourceSurface for a gfxASurface. This surface should -not- be
> +     * held around by the user after the underlying gfxASurface has been
> +     * destroyed as a copy of the data is not guaranteed.
> +     */

This strikes me as sort of fragile. Not sure I have a good suggestion other than document the users as well as here as a reminder to be careful.
Comment 7 Bas Schouten (:bas.schouten) 2012-05-21 08:12:23 PDT
Created attachment 625654 [details] [diff] [review]
Part 2: Deal with CreateSourceSurfaceFromData failing. v2

While processing review comments I found a bug where we could keep around a sourceSurface without keeping around the gfxASurface. This patch fixes that issue.
Comment 8 Ed Morley [:emorley] 2012-05-21 11:12:46 PDT
Sorry, had to back out the push for Win debug crashes:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=a693c64dc64e

https://hg.mozilla.org/integration/mozilla-inbound/rev/b4e62a1e9809

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