756767 - [Azure] Reduce memory peaks due to surface creation

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Bas Schouten (:bas.schouten)]

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

Attachment: Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support.

Comment 2

[Bas Schouten (:bas.schouten)]

Attachment: Part 2: Deal with CreateSourceSurfaceFromData failing.

Comment 3

[Bas Schouten (:bas.schouten)]

Attachment: Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support. v2

Add files missing in first patch.

Comment 4

[Bas Schouten (:bas.schouten)]

It does block enabling by default, as it causes occasional OOM on a reftest on Tryserver.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

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

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

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

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

Comment 9

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/63a4c2f2a0b9
https://hg.mozilla.org/integration/mozilla-inbound/rev/bbb12d0bcf49

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/63a4c2f2a0b9
https://hg.mozilla.org/mozilla-central/rev/bbb12d0bcf49