* SUMMARY Add an updateLayoutForResize method to the View base class. A handful of classes cache the size/position of DOM elements to avoid unnecessary reflows during layout. It would be useful to have a generic way to inform a view that it's size has changed, and to propagate this to the view's children.
<rdar://problem/24430938>
Created attachment 270355 [details] [Patch] Proposed Fix
Comment on attachment 270355 [details] [Patch] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=270355&action=review > Source/WebInspectorUI/ChangeLog:42 > + Overridden by views that need to perform resize logic, such as If this is always going to happen in the same event loop as the actual layout, what's the benefit of splitting this from updateLayoutForResize implementations?
(In reply to comment #3) > Comment on attachment 270355 [details] > [Patch] Proposed Fix > > View in context: > https://bugs.webkit.org/attachment.cgi?id=270355&action=review > > > Source/WebInspectorUI/ChangeLog:42 > > + Overridden by views that need to perform resize logic, such as > > If this is always going to happen in the same event loop as the actual > layout, what's the benefit of splitting this from updateLayoutForResize > implementations? Another way of thinking about this might be: can we pass a LayoutUpdateReason enum {Resize, Dirty} as an argument to updateLayout(), and would this be clearer than two separate methods with an implicit contract about the calling order? My hunch is yes, but maybe I'm missing something.
(In reply to comment #4) > (In reply to comment #3) > > Comment on attachment 270355 [details] > > [Patch] Proposed Fix > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=270355&action=review > > > > > Source/WebInspectorUI/ChangeLog:42 > > > + Overridden by views that need to perform resize logic, such as > > > > If this is always going to happen in the same event loop as the actual > > layout, what's the benefit of splitting this from updateLayoutForResize > > implementations? > > Another way of thinking about this might be: can we pass a > LayoutUpdateReason enum {Resize, Dirty} as an argument to updateLayout(), > and would this be clearer than two separate methods with an implicit > contract about the calling order? My hunch is yes, but maybe I'm missing > something. I like this suggestion. The optional argument can be passed to needsLayout as well as updateLayout, making it more flexible than this approach. There used to exist an updateLayoutForResize method prior to all the View refactoring, which is what I initially based this on.
Created attachment 270444 [details] [Patch] Proposed Fix
Created attachment 270446 [details] [Patch] Proposed Fix
Comment on attachment 270446 [details] [Patch] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=270446&action=review r=me, but please check that TimelineRuler has not turned into a performance problem. > Source/WebInspectorUI/ChangeLog:41 > + update cached client width if resized. Nit: 'Update' > Source/WebInspectorUI/UserInterface/Views/View.js:304 > + Dirty: Symbol("layout-layoutReason-dirty"), Nit: view-layout-reason-dirty
(In reply to comment #8) > Comment on attachment 270446 [details] > [Patch] Proposed Fix > > View in context: > https://bugs.webkit.org/attachment.cgi?id=270446&action=review > > r=me, but please check that TimelineRuler has not turned into a performance > problem. Did ad hoc testing, looks okay! > > > Source/WebInspectorUI/ChangeLog:41 > > + update cached client width if resized. > > Nit: 'Update' > > > Source/WebInspectorUI/UserInterface/Views/View.js:304 > > + Dirty: Symbol("layout-layoutReason-dirty"), > > Nit: view-layout-reason-dirty Find-replace error. Ugh.
Created attachment 270451 [details] [Patch] Proposed Fix
Comment on attachment 270451 [details] [Patch] Proposed Fix Clearing flags on attachment: 270451 Committed r195995: <http://trac.webkit.org/changeset/195995>
All reviewed patches have been landed. Closing bug.