Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(511)

Issue 603053002: Move RenderSVGImage's paint code to SVGImagePainter (Closed)

Created:
6 years, 3 months ago by pdr.
Modified:
6 years, 1 month ago
Reviewers:
chrishtr, f(malita), fs
CC:
blink-reviews, blink-reviews-rendering, zoltan1, rwlbuis, pdr+renderingwatchlist_chromium.org, eae+blinkwatch, leviw+renderwatch, kouhei+svg_chromium.org, fs, ed+blinkwatch_opera.com, krit, f(malita), gyuyoung.kim_webkit.org, jchaffraix+rendering, Stephen Chennney, pdr+svgwatchlist_chromium.org, rune+blink, slimming-paint-reviews_google.com
Project:
blink
Visibility:
Public.

Description

Move RenderSVGImage's paint code to SVGImagePainter This patch moves RenderSVGImage's paint functions to SVGImagePainter. This is a straight code refactor with no changes other than exposing a few functions on RenderSVGImage. The one hairy part of this patch is the buffered rendering support we have in RenderSVGImage. This has been moved to a static function on SVGImagePainter and all callers have been updated. BUG=412088 Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=182704

Patch Set 1 #

Total comments: 1
Unified diffs Side-by-side diffs Delta from patch set Stats (+116 lines, -62 lines) Patch
M Source/core/core.gypi View 1 chunk +2 lines, -0 lines 0 comments Download
A Source/core/paint/SVGImagePainter.h View 1 chunk +28 lines, -0 lines 0 comments Download
A Source/core/paint/SVGImagePainter.cpp View 1 chunk +77 lines, -0 lines 0 comments Download
M Source/core/rendering/svg/RenderSVGImage.h View 1 chunk +5 lines, -6 lines 1 comment Download
M Source/core/rendering/svg/RenderSVGImage.cpp View 2 chunks +2 lines, -55 lines 0 comments Download
M Source/core/rendering/svg/SVGRenderingContext.cpp View 2 chunks +2 lines, -1 line 0 comments Download

Messages

Total messages: 10 (4 generated)
pdr.
6 years, 3 months ago (2014-09-25 05:43:25 UTC) #2
fs
lgtm
6 years, 2 months ago (2014-09-25 11:09:59 UTC) #4
commit-bot: I haz the power
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/603053002/1
6 years, 2 months ago (2014-09-25 18:06:50 UTC) #6
commit-bot: I haz the power
Committed patchset #1 (id:1) as 182704
6 years, 2 months ago (2014-09-25 18:55:10 UTC) #7
f(malita)
https://codereview.chromium.org/603053002/diff/1/Source/core/rendering/svg/RenderSVGImage.h File Source/core/rendering/svg/RenderSVGImage.h (right): https://codereview.chromium.org/603053002/diff/1/Source/core/rendering/svg/RenderSVGImage.h#newcode47 Source/core/rendering/svg/RenderSVGImage.h:47: OwnPtr<ImageBuffer>& bufferedForeground() { return m_bufferedForeground; } Belated comment: encapsulation-- ...
6 years, 2 months ago (2014-10-24 20:11:53 UTC) #9
chrishtr
6 years, 1 month ago (2014-10-27 03:38:35 UTC) #10
Message was sent while issue was closed.
On 2014/10/24 at 20:11:53, fmalita wrote:
>
https://codereview.chromium.org/603053002/diff/1/Source/core/rendering/svg/Re...
> File Source/core/rendering/svg/RenderSVGImage.h (right):
> 
>
https://codereview.chromium.org/603053002/diff/1/Source/core/rendering/svg/Re...
> Source/core/rendering/svg/RenderSVGImage.h:47: OwnPtr<ImageBuffer>&
bufferedForeground() { return m_bufferedForeground; }
> Belated comment: encapsulation-- :(
> 
> Do we have a general strategy for passing private renderer info to painters?
> 
> Some options
> 
> 1) make all needed info a (packaged?) param to paint() - this will not fly if
we want paint() to follow a uniform interface (which I believe is desirable)
> 
> 2) pass all info to the painter constructor
> 
> 3) befriend painters <-> renderers
> 
> I'm thinking #2 is preferable, but honestly I would take any of them over
exposing renderer guts publicly :)

The plan is to expose the things that are need as public, and then package them
later once all painters are implemented. Making them public in the meantime is
not amazing, but we are prioritizing speed & simplicity of the refactoring over
that.

(Friend classes in particular are not a good solution since they expose
non-public info.)

Powered by Google App Engine
This is Rietveld 408576698