[Azure] Reduce memory peaks due to surface creation

RESOLVED FIXED in mozilla15

Status

()

Core
Graphics
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bas, Assigned: bas)

Tracking

unspecified
mozilla15
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

5 years ago
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)
(Assignee)

Updated

5 years ago
Blocks: 715768
(Assignee)

Comment 1

5 years ago
Created attachment 625401 [details] [diff] [review]
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support.
Attachment #625401 - Flags: review?(jmuizelaar)
(Assignee)

Comment 2

5 years ago
Created attachment 625402 [details] [diff] [review]
Part 2: Deal with CreateSourceSurfaceFromData failing.
Attachment #625402 - Flags: review?(jmuizelaar)
No longer blocks: 715768
(Assignee)

Comment 3

5 years ago
Created attachment 625413 [details] [diff] [review]
Part 1: Simplify SourceSurfaceD2D and add DataSourceSurface support. v2

Add files missing in first patch.
Attachment #625401 - Attachment is obsolete: true
Attachment #625401 - Flags: review?(jmuizelaar)
(Assignee)

Updated

5 years ago
Attachment #625413 - Attachment is patch: true
Attachment #625413 - Flags: review?(jmuizelaar)
(Assignee)

Comment 4

5 years ago
It does block enabling by default, as it causes occasional OOM on a reftest on Tryserver.
Blocks: 715768
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()
Attachment #625413 - Flags: review?(jmuizelaar) → review+
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.
Attachment #625402 - Flags: review?(jmuizelaar) → review+
(Assignee)

Comment 7

5 years ago
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.
Attachment #625402 - Attachment is obsolete: true
Attachment #625654 - Flags: review?(jmuizelaar)
Attachment #625654 - Flags: review?(jmuizelaar) → review+

Comment 8

5 years ago
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
(Assignee)

Comment 9

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/63a4c2f2a0b9
https://hg.mozilla.org/integration/mozilla-inbound/rev/bbb12d0bcf49
https://hg.mozilla.org/mozilla-central/rev/63a4c2f2a0b9
https://hg.mozilla.org/mozilla-central/rev/bbb12d0bcf49
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
You need to log in before you can comment on or make changes to this bug.