Wrap SVGImage for container during paint

Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint.

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

One quirk is the added BackgroundImageGeometry::imageContainerSize()
containing the tile size before 'background-repeat: round' has been
applied. Before this patch, this size was the one kept for the
respective container in ImageResource (since
setContainerSizeForLayoutObject were called before tile size
adjustments for background-repeat: round). It turns out this is
important to get the stretching correct, i.e. makes the underlying
drawing code ignore the intrinsic ratio of the background
image. svg/as-background-image/background-repeat.html exercises this
behavior.

BUG=128055, 306222
Committed: https://crrev.com/6546ae27e63ffbcca7c35da35eddae9f092ca35b
Cr-Commit-Position: refs/heads/master@{#360558}

[davve, 2015-10-30 11:03:34]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-10-30 11:03:56]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/1

[commit-bot: I haz the power, 2015-10-30 11:22:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-30 11:22:56]

Dry run: Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)

[davve, 2015-10-30 14:48:40]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-10-30 14:49:15]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/20001

[commit-bot: I haz the power, 2015-10-30 15:49:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-30 15:49:43]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[davve, 2015-11-02 08:21:55]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-02 08:22:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/40001

[commit-bot: I haz the power, 2015-11-02 09:35:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-02 09:35:41]

Dry run: This issue passed the CQ dry run.

[davve, 2015-11-02 12:39:30]

Description was changed from

==========
Allocate SVGImageForContainer during paint

BUG=128055
==========

to

==========
Allocate SVGImageForContainer during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this:

1. It's racy. setContainerSizeForLayoutObject is called sometime from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint.

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size for themselves. This required
some new code in LayoutListMarker for computing the size when it's
needed.

BUG=128055, 550389
==========

[davve, 2015-11-02 13:39:32]

Description was changed from

==========
Allocate SVGImageForContainer during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this:

1. It's racy. setContainerSizeForLayoutObject is called sometime from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint.

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size for themselves. This required
some new code in LayoutListMarker for computing the size when it's
needed.

BUG=128055, 550389
==========

to

==========
Allocate SVGImageForContainer during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this:

1. It's racy. setContainerSizeForLayoutObject is called sometime from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint.

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size for themselves. This required
some new code in LayoutListMarker for computing the size when it's
needed.

BUG=128055, 306222
==========

[davve, 2015-11-02 13:41:30]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-02 13:41:47]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/60001

[davve, 2015-11-02 13:48:58]

Description was changed from

==========
Allocate SVGImageForContainer during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this:

1. It's racy. setContainerSizeForLayoutObject is called sometime from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint.

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size for themselves. This required
some new code in LayoutListMarker for computing the size when it's
needed.

BUG=128055, 306222
==========

to

==========
Allocate SVGImageForContainer during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

BUG=128055, 306222
==========

[commit-bot: I haz the power, 2015-11-02 14:59:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-02 14:59:07]

Dry run: This issue passed the CQ dry run.

[davve, 2015-11-03 09:46:57]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-03 09:47:20]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/80001

[commit-bot: I haz the power, 2015-11-03 12:08:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-03 12:08:40]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[davve, 2015-11-04 13:13:24]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-04 13:13:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/100001

[davve, 2015-11-04 13:15:29]

The CQ bit was unchecked by davve@opera.com

[commit-bot: I haz the power, 2015-11-04 13:15:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-04 13:15:38]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[davve, 2015-11-04 14:24:30]

Description was changed from

==========
Allocate SVGImageForContainer during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

BUG=128055, 306222
==========

to

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

BUG=128055, 306222
==========

[davve, 2015-11-04 14:27:37]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-04 14:27:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/140001

[davve, 2015-11-04 14:28:55]

Description was changed from

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainers, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

BUG=128055, 306222
==========

to

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

BUG=128055, 306222
==========

[davve, 2015-11-04 14:36:09]

Description was changed from

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

BUG=128055, 306222
==========

to

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

Another quirk in here is the added
BackgroundImageGeometry::tileSizeBeforeRound() containing the tile
size before 'background-repeat: round' has been applied. Before this
patch, this size was the one kept for the respective container in
ImageResource (since setContainerSizeForLayoutObject were called
before tile size adjustments for background-repeat: round). It turns
out this is important to get the stretching correct, i.e. makes the
underlying drawing code ignore the intrinsic ratio of the background
image.  In LayoutTests, svg/as-background-image/background-repeat.html
exercises this behavior.

BUG=128055, 306222
==========

[commit-bot: I haz the power, 2015-11-04 15:28:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-04 15:28:30]

Dry run: This issue passed the CQ dry run.

[davve, 2015-11-11 08:40:14]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-11 08:40:32]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/180001

[davve, 2015-11-11 08:42:03]

Description was changed from

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

Generated image (gradients) gets an honorary mention as
well. StyleGeneratedImage used setContainerSizeForLayoutObject for its
own usage, to store the size of the generated image area. Now that
setContainerSizeForLayoutObject is gone, the user of the
StyleGeneratedImage must track the size itself. This required some new
code in LayoutListMarker for computing the size when it's needed.

Another quirk in here is the added
BackgroundImageGeometry::tileSizeBeforeRound() containing the tile
size before 'background-repeat: round' has been applied. Before this
patch, this size was the one kept for the respective container in
ImageResource (since setContainerSizeForLayoutObject were called
before tile size adjustments for background-repeat: round). It turns
out this is important to get the stretching correct, i.e. makes the
underlying drawing code ignore the intrinsic ratio of the background
image.  In LayoutTests, svg/as-background-image/background-repeat.html
exercises this behavior.

BUG=128055, 306222
==========

to

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

One quirk is the added BackgroundImageGeometry::tileSizeBeforeRound()
containing the tile size before 'background-repeat: round' has been
applied. Before this patch, this size was the one kept for the
respective container in ImageResource (since
setContainerSizeForLayoutObject were called before tile size
adjustments for background-repeat: round). It turns out this is
important to get the stretching correct, i.e. makes the underlying
drawing code ignore the intrinsic ratio of the background
image. svg/as-background-image/background-repeat.html exercises this
behavior.

BUG=128055, 306222
==========

[commit-bot: I haz the power, 2015-11-11 09:59:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-11 09:59:42]

Dry run: This issue passed the CQ dry run.

[davve, 2015-11-13 14:43:05]

davve@opera.com changed reviewers:
+ fmalita@chromium.org, fs@opera.com, pdr@chromium.org

[davve, 2015-11-13 14:43:06]

fs, something to gently nudge forward the coming week, you think? I
add pdr@ and fmalita@ as reviewers too, both seem to have done work in
the vicinity.

fs and I discussed implications to bug 472129 (doing layout during
paint in SVGImage::draw()) and whether this moves us in the wrong
direction. I don't think so, since we'd have less
SVGImageForContainer. The jump to using plain and unique SVGImage
should be smaller, if we choose to take that step. But that remains to
be seen, of course.

The main motivation for this patch initially was to make it easier to
implement fragments properly. I have a CL almost ready to do this, but
I think this CL turned out interesting on its own for the reasons I
state in the description.

[fs, 2015-11-13 18:09:32]

On 2015/11/13 at 14:43:06, davve wrote:
> fs, something to gently nudge forward the coming week, you think?

SGTM, I'll queue this up for Monday (jetlagged reviews may or may not be
good...) This should prevent...

> I
> add pdr@ and fmalita@ as reviewers too, both seem to have done work in
> the vicinity.

...other reviewers to chime in of course.

> fs and I discussed implications to bug 472129 (doing layout during
> paint in SVGImage::draw()) and whether this moves us in the wrong
> direction. I don't think so, since we'd have less
> SVGImageForContainer. The jump to using plain and unique SVGImage
> should be smaller, if we choose to take that step. But that remains to
> be seen, of course.

Yes, I think this is mostly (if not entirely) orthogonal (and that bug 472129
will be difficult to solve.)

[fs, 2015-11-16 15:08:07]

Looks mostly ok to me (see question in SVGImagePainter). There's still things
that could be meditated upon though (like how to best handle the wrapping
without requiring it at every usage site) - and possible cleanups
(imageSizeForLayoutObject). The latter seems reasonable to leave for now though.
I'd appreciate any input on the former though, although I don't see the need to
block on that.

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutImageResource.h (left):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutImageResource.h:69: virtual
LayoutSize intrinsicSize(float multiplier) const { return
getImageSize(multiplier, ImageResource::IntrinsicSize); }
(I guess this choice of keeping imageSize over intrinsicSize was made because of
the *StyleImage derivation?)

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/SVGImagePainter.cpp (right):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/SVGImagePainter.cpp:36: return;
Won't this mean that we could miss out on some of the "effects" below?
('filter', 'outline', etc.) The area to draw into could still be non-empty.

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/SVGImagePainter.cpp:60: RefPtr<Image> image
= imageResource->image(expandedIntSize(imageViewportSize),
m_layoutSVGImage.style()->effectiveZoom());
expandedIntSize used to be roundedIntSize I think, but expanding does seem
slightly more reasonable to me.

[davve, 2015-11-16 16:32:40]

Input on how to handle the wrapping are very much welcome. I agree the
way of the current CL isn't optimal and a bit ad-hoc. I might as well
add fs's "thinking out loud"-suggestion to add a virtual method on
Image, somthing like Image::wrapForContainer, to the mix. I haven't
actually implemented it but sounds like a workable solution from the
face of it, but I'm not sure the ad-hocness would go away.

Cleaning up imageSizeForLayoutObject to not take a layoutObject is a
bit tempting, yes (and pass image orientation info another way).

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutImageResource.h (left):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutImageResource.h:69: virtual
LayoutSize intrinsicSize(float multiplier) const { return
getImageSize(multiplier, ImageResource::IntrinsicSize); }
On 2015/11/16 15:08:07, fs wrote:
> (I guess this choice of keeping imageSize over intrinsicSize was made because
of
> the *StyleImage derivation?)

Yes, but I could go the other way too. imageSize should mean the intrinsicSize
so shouldn't really matter.

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/SVGImagePainter.cpp (right):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/SVGImagePainter.cpp:36: return;
On 2015/11/16 15:08:07, fs wrote:
> Won't this mean that we could miss out on some of the "effects" below?
> ('filter', 'outline', etc.) The area to draw into could still be non-empty.

Moving the check to SVGImagePainter::paintForeground (where I had it the first 7
or so patch sets) seems reasonable. Testing the expanded (int)size seems to make
more sense too.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3750

is one example where it actually makes a difference. I had to pull out
preserveAspectRatio='none' to trigger it. But that whole business in
computeImageViewport seems a bit fishy to me.

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/SVGImagePainter.cpp:60: RefPtr<Image> image
= imageResource->image(expandedIntSize(imageViewportSize),
m_layoutSVGImage.style()->effectiveZoom());
On 2015/11/16 15:08:07, fs wrote:
> expandedIntSize used to be roundedIntSize I think, but expanding does seem
> slightly more reasonable to me.

Yes, I couldn't really make sense of that.

[f(malita), 2015-11-16 16:36:15]

I really like the direction of this CL.

A bit concerned about all the state micromanagement going on (setURL,
setTileSize, etc.) - but those appear to be inherited warts.

So I'm mostly ok with this too, and hoping we can clean up some of the gremlins
you dragged out into the light at some point :)

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BackgroundImageGeometry.h (right):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BackgroundImageGeometry.h:33: IntSize
tileSizeBeforeRound() const { return m_tileSizeBeforeRound; }
I find the current name confusing - is there a better choice?  Maybe
imageContainerSize?

[fs, 2015-11-16 16:43:21]

LGTM

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/SVGImagePainter.cpp (right):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/SVGImagePainter.cpp:36: return;
On 2015/11/16 at 16:32:40, David Vest wrote:
> On 2015/11/16 15:08:07, fs wrote:
> > Won't this mean that we could miss out on some of the "effects" below?
> > ('filter', 'outline', etc.) The area to draw into could still be non-empty.
> 
> Moving the check to SVGImagePainter::paintForeground (where I had it the first
7 or so patch sets) seems reasonable. Testing the expanded (int)size seems to
make more sense too.
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3750
> 
> is one example where it actually makes a difference. I had to pull out
preserveAspectRatio='none' to trigger it. But that whole business in
computeImageViewport seems a bit fishy to me.

Yes, computeImageViewport is fishy business (said one of the fishermen...)

[davve, 2015-11-17 12:13:56]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-17 12:14:27]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/220001

[davve, 2015-11-17 12:15:02]

Description was changed from

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

One quirk is the added BackgroundImageGeometry::tileSizeBeforeRound()
containing the tile size before 'background-repeat: round' has been
applied. Before this patch, this size was the one kept for the
respective container in ImageResource (since
setContainerSizeForLayoutObject were called before tile size
adjustments for background-repeat: round). It turns out this is
important to get the stretching correct, i.e. makes the underlying
drawing code ignore the intrinsic ratio of the background
image. svg/as-background-image/background-repeat.html exercises this
behavior.

BUG=128055, 306222
==========

to

==========
Wrap SVGImage for container during paint

Before this patch, one SVGImageForContainer object is saved in
ImageResource for each corresponding use of SVGImage.

<img style="width: 1000px" src="image.svg">
...
<img style="width: 500px" src="image.svg">

This example would give one ImageResource (for image.svg) and within
it two SVGImageForContainer, one for each <img>. SVGImageForContainer
contains the unzoomed container size along with the zoom level,
indexed on the layout object of the container in
SVGImageFor*Container*.

There were at least three problems with this approach:

1. It's racy. setContainerSizeForLayoutObject is called sometimes from
   layout(), sometimes during paint(). Users of APIs such as
   imageForLayoutObject or imageSizeForLayoutObject that depend on
   setContainerSizeForLayoutObject would get different results
   depending on when they are called. Basically the only "safe" time
   to call these methods are right before paint. 

2. It limits the number of associations between layout object and
   SVGImage to one. Consider an element/layout object having one
   SVGImage as content and another SVGImage as background. The
   container size for those two SVGImages in this case isn't
   necessarily the same and strictly speaking we should need two
   SVGImageForContainer objects. Only one SVGImageForContainer can be
   stored per layout object.

3. It breaks layering. ImageResource lives in fetch and having fetch/
   depend on svg code is undesirable. DEPS for fetch/ states
   "core/fetch/ shouldn't depend on anything else in core/".

After this patch, these three problems have been
addressed. SVGImageForContainer is now only allocated when it's
needed, to be passed through the GraphicsContext layer as a wrapper to
get the correct size and zoom level to avoid pixelated rasterization.

There are risks with this patch. In some cases code may rely on having
the container size saved inside ImageResource.cpp. However, such code
is most often already brittle and unreliable due to (1) above.

One quirk is the added BackgroundImageGeometry::imageContainerSize()
containing the tile size before 'background-repeat: round' has been
applied. Before this patch, this size was the one kept for the
respective container in ImageResource (since
setContainerSizeForLayoutObject were called before tile size
adjustments for background-repeat: round). It turns out this is
important to get the stretching correct, i.e. makes the underlying
drawing code ignore the intrinsic ratio of the background
image. svg/as-background-image/background-repeat.html exercises this
behavior.

BUG=128055, 306222
==========

[davve, 2015-11-17 13:08:29]

> A bit concerned about all the state micromanagement going on (setURL,
> setTileSize, etc.) - but those appear to be inherited warts.

I agree fully.

> So I'm mostly ok with this too, and hoping we can clean up some of the
gremlins
> you dragged out into the light at some point :)

I hope so too!

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BackgroundImageGeometry.h (right):

https://codereview.chromium.org/1427943002/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BackgroundImageGeometry.h:33: IntSize
tileSizeBeforeRound() const { return m_tileSizeBeforeRound; }
On 2015/11/16 16:36:14, f(malita) wrote:
> I find the current name confusing - is there a better choice?  Maybe
> imageContainerSize?

Yes, that's probably a better name.

[commit-bot: I haz the power, 2015-11-17 13:34:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-17 13:34:41]

Dry run: This issue passed the CQ dry run.

[f(malita), 2015-11-18 04:12:59]

Thanks, LGTM!

[davve, 2015-11-18 13:07:46]

The CQ bit was checked by davve@opera.com

[davve, 2015-11-18 13:07:47]

The patchset sent to the CQ was uploaded after l-g-t-m from fs@opera.com
Link to the patchset: https://codereview.chromium.org/1427943002/#ps220001
(title: "Rename beforeRound -> imageContainerSize")

[commit-bot: I haz the power, 2015-11-18 13:08:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/220001

[commit-bot: I haz the power, 2015-11-18 13:16:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 13:16:02]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[davve, 2015-11-18 13:34:28]

davve@opera.com changed reviewers:
+ kbr@chromium.org

[davve, 2015-11-18 13:34:29]

Ken, can you review modules/webgl/ when you have a moment?

[Ken Russell (switch to Gerrit), 2015-11-18 17:43:58]

modules/webgl lgtm as long as the webgl_conformance tests pass.

[davve, 2015-11-19 07:48:58]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-19 07:49:36]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/220001

[commit-bot: I haz the power, 2015-11-19 08:18:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-19 08:18:29]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[davve, 2015-11-19 08:52:03]

The CQ bit was checked by davve@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-19 08:52:52]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/240001

[commit-bot: I haz the power, 2015-11-19 10:34:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-19 10:34:22]

Dry run: This issue passed the CQ dry run.

[davve, 2015-11-19 10:44:45]

The CQ bit was checked by davve@opera.com

[davve, 2015-11-19 10:44:45]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
fmalita@chromium.org, fs@opera.com
Link to the patchset: https://codereview.chromium.org/1427943002/#ps240001
(title: "Use IntSize for SVGImageForContainer")

[commit-bot: I haz the power, 2015-11-19 10:45:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1427943002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1427943002/240001

[davve, 2015-11-19 10:46:19]

On 2015/11/18 17:43:58, Ken Russell wrote:
> modules/webgl lgtm as long as the webgl_conformance tests pass.

Thanks. webgl_conformance tests seems fine on the bots.

[commit-bot: I haz the power, 2015-11-19 10:49:55]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2015-11-19 10:50:55]

Patchset 13 (id:??) landed as
https://crrev.com/6546ae27e63ffbcca7c35da35eddae9f092ca35b
Cr-Commit-Position: refs/heads/master@{#360558}