Created attachment 137560 [details] Patch

Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

Attachment 137560 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/plat..." exit_code: 1 Source/Platform/chromium/public/WebLayer.h:30: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 36 files If any of these errors are false positives, please file a bug against check-webkit-style.

What's the use case here that's not solved by inserting a smaller layer with a background filter prior to the larger layer?

Aura uses a single layer for the window frame and adding extra layers == more video memory. This was requested to allow them to just set blur on the title area, without having to nest it in a separate view.

Comment on attachment 137560 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=137560&action=review > Source/Platform/chromium/public/WebLayer.h:113 > + WEBKIT_EXPORT void setBackgroundFilterInsets(int top, int right, int bottom, int left); why isn't this a WebRect? why is this specified as insets instead of a rectangle in the layer's space? what happens when bounds change? > Source/WebCore/platform/graphics/chromium/LayerChromium.cpp:75 > + , m_backgroundFilterInsetTop(0) > + , m_backgroundFilterInsetRight(0) > + , m_backgroundFilterInsetBottom(0) > + , m_backgroundFilterInsetLeft(0) this should be an IntRect. it's pretty much always wrong to have a matched set of ints to represent a rectangle > Source/WebCore/platform/graphics/chromium/LayerChromium.h:126 > + void setBackgroundFilterInsets(int top, int right, int bottom, int left); take a rect type > Source/WebCore/platform/graphics/chromium/LayerChromium.h:127 > + void getBackgroundFilterInsets(int& top, int& right, int& bottom, int& left); just return a rect type by value and name this like a normal getter

Comment on attachment 137560 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=137560&action=review >> Source/Platform/chromium/public/WebLayer.h:113 >> + WEBKIT_EXPORT void setBackgroundFilterInsets(int top, int right, int bottom, int left); > > why isn't this a WebRect? > > why is this specified as insets instead of a rectangle in the layer's space? what happens when bounds change? That is why. It's relative to the edges of the bounds rect. If the rect changes the insets remain the same. Ben suggested doing it this way.

Do we have a type to represent top/bottom/left/right? IntRect isn't quite that type... but this keeps coming up!

FYI, the intent of this is to allow us to apply a filter only to a subset of a layer. Expressed most generically, this could be any sub-region of the layer, though to begin with it is simple to think of this control as "extend the filter into the layer by these insets". I have no preference as to whether this is exposed as a set of insets, or a region. Note that when I speak of insets I mean the effect should apply in the insets, not that the effect should be inset by those insets. For a function implementing similar functionality on a different platform see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa969512(v=vs.85).aspx

(In reply to comment #9) > FYI, the intent of this is to allow us to apply a filter only to a subset of a layer. > > Expressed most generically, this could be any sub-region of the layer, though to begin with it is simple to think of this control as "extend the filter into the layer by these insets". I have no preference as to whether this is exposed as a set of insets, or a region. > > Note that when I speak of insets I mean the effect should apply in the insets, not that the effect should be inset by those insets. Oh! I misunderstood the intent and can fix this up. James, does this sound like a reasonable API to you or do you have something else you'd prefer for this?

I think I would prefer to begin with a single rect as opposed to insets, as it is a simpler first iteration. Insets basically equate to between 0 and 4 rects. Will adjust the public API to match.

(In reply to comment #8) > Do we have a type to represent top/bottom/left/right? IntRect isn't quite that type... but this keeps coming up! How about at least adding to e.g. class IntRect: void inset(const IntSize& leftTop, const IntSize& rightBottom) { m_location += leftTop; m_size -= leftTop + rightBottom; } We might also have a new class IntRectInset with IntSize members m_leftTopInset, m_rightBottomInset (or just m_leftTop, m_rightBottom). IntRectInset or LayoutUnitRectInset or LayoutUnitInset could then be used for margins, borders, padding, intrinsic padding, etc. I think an "IntRectDelta" (difference between two rects) is less useful, as usually adding vectors to a rect's leftTop & bottomRight is ok as a rect.move() followed by rect.expand() or rect.contract().

Comment on attachment 137560 [details] Patch Pending feedback from UI people. There is already an API that would allow a clear layer with the background filter to be placed below the content layer where the filter should be applied.