• Home
  • History
  • Annotate
  • Raw
  • Download
  • only in /macosx-10.10/WebCore-7600.1.25/page/

Lines Matching defs:layout

555         m_setNeedsLayoutWasDeferred = false; // FIXME: Find a way to make the deferred layout actually happen.
710 // If we expect to update compositing after an incipient layout, don't do so here.
858 // If we sync compositing layers when a layout is pending, we may cause painting of compositing
859 // layer content to occur before layout has happened, which will cause paintContents() to bail.
954 layout();
1061 // layout without knowing about the existence of the embedded SVG document, because RenderReplaced
1063 // bothering to lay out the SVG document, mark the ownerRenderer needing layout and ask its
1064 // FrameView for a layout. After that the RenderEmbeddedObject (ownerRenderer) carries the
1069 // Mark the owner renderer as needing layout.
1072 // Synchronously enter layout, to layout the view containing the host object/embed/iframe.
1073 frameView->layout();
1076 void FrameView::layout(bool allowSubtree)
1081 // Protect the view from being deleted during layout (in recalcStyle).
1084 // Many of the tasks performed during layout can cause this function to be re-entered,
1085 // so save the layout phase now and restore it on exit.
1088 // Every scroll that happens during layout is programmatic.
1109 // we shouldn't enter layout() while painting
1134 // This is a new top-level layout. If there are any remaining tasks from the previous
1135 // layout, finish them now.
1156 // the layout beats any sort of style recalc update that needs to occur.
1163 // so there's no point to continuing to layout
1199 printf("Elapsed time before first layout: %lld\n", document.elapsedTime().count());
1272 root->layout();
1280 root->layout();
1285 root->layout();
1350 // If we need layout or are already in a synchronous call to postLayoutTasks(),
1356 layout();
1962 // We need to update the layout before scrolling, otherwise we could
1965 // Only do a layout if changes have occurred that make it necessary.
1968 layout();
2076 // If we're scrolling as a result of updating the view size after layout, we'll update widgets and layer positions soon anyway.
2225 // An ASSERT is triggered when a view schedules a layout before being attached to a frame.
2241 // triggered when a view is layout before being attached to a frame().
2258 layout();
2375 layout();
2395 // When frame flattening is enabled, the contents of the frame could affect the layout of the parent frames.
2410 printf("Scheduling layout for %d\n", delay);
2491 // layout in that case.
2834 // Only send layout-related delegate callbacks synchronously for the main frame to
2835 // avoid re-entering layout for the main frame while delivering a layout-related delegate
2852 // layout() protects FrameView, but it still can get destroyed when updateEmbeddedObjects()
2853 // is called through the post layout timer.
3505 // When we start a layout at the child level as opposed to the topmost frame view and this child
3506 // frame requires flattening, we need to re-initiate the layout at the topmost view. Layout
3512 // In the middle of parent layout, no need to restart from topmost.
3516 // Parent tree is clean. Starting layout from it would have no effect.
3523 parentView->layout(allowSubtree);
3548 layout();
3776 // layout and make sure they are up to date.
3778 // update layout for frames that are outside the dirty region. Not only does this seem
3779 // pointless (since those frames will have set a zero timer to layout anyway), but
3787 layout();
3790 // calls, as they can potentially re-enter a layout of the parent frame view, which may add/remove scrollbars
3803 // needs to call layout on parent frame recursively.
3804 // This assert ensures that parent frames are clean, when child frames finished updating layout and style.
3870 layout(allowSubtree);
3876 // the state of things before and after the layout
4092 // Force layout to flush out any pending repaints.
4385 // If the layout was done with pending sheets, we are not in fact visually non-empty yet.
4482 // updateWidgetPosition() can possibly cause layout to be re-entered (via plug-ins running