[Webkit-unassigned] [Bug 168128] [GTK] Version 2.14.4 does not paint most websites

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=168128

--- Comment #10 from Adrian Perez <aperez at igalia.com> ---
Created attachment 301303
  --> https://bugs.webkit.org/attachment.cgi?id=301303&action=review
Patch to add debug-prints in DrawingAreaImpl.cpp

With this patch applied, running MiniBrowser results in the following output:

  % run-minibrowser --gtk --debug        
  Starting MiniBrowser.
 DrawingAreaImpl: instantiated!
  updatePreferences
    AC enabled: yes
    AC forced: no
    layerTreeHost: 0x7fea80741fdd
  updateBackingStoreState
    m_forceRepaintAfterBackingStoreStateUpdate: no
  enterAcceleratedCompositingMode((nil))
  setNeedsDisplay
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplay()
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  ...
  (keeps repeating until resizing the window)
  ...
  mainFrameContentSizeChanged
    m_layerTreeHost -> delegating
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  ...
  (keeps repeating)

The output with “WEBKIT_DISABLE_COMPOSITING_MODE=1” is the same except for
the 4th line, which report “AC enabled: no”. The, with AC forced, the output
becomes:

  % WEBKIT_FORCE_COMPOSITING_MODE=1 run-minibrowser --gtk --debug
  Starting MiniBrowser.
  DrawingAreaImpl: instantiated!
  updatePreferences
    AC enabled: yes
    AC forced: yes
    layerTreeHost: 0x7f7997961fdd
    will call enterAcceleratedCompositingMode(nullptr)
  enterAcceleratedCompositingMode((nil))
  updateBackingStoreState
    m_forceRepaintAfterBackingStoreStateUpdate: no
  setNeedsDisplay
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplay()
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  ...
  (repeats a few times)
  ...
  mainFrameContentSizeChanged
    m_layerTreeHost -> delegating
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  setRootCompositingLayer
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  didUpdateBackingStoreState
  setNeedsDisplay
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplay()
  sendDidUpdateBackingStoreState
  setRootCompositingLayer
  setRootCompositingLayer
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  setNeedsDisplayInRect
    m_layerTreeHost -> AcceleratedDrawingArea::setNeedsDisplayInRect()
  mainFrameContentSizeChanged
    m_layerTreeHost -> delegating
  mainFrameContentSizeChanged
    m_layerTreeHost -> delegating

With AC disabled, methods in AcceleratedDrawingArea are also called, which sounds
odd in my head (note that I am not familiar with the AC vs. non-AC code paths, I am
just pointing out what sounds odd to me). What should be the condition that determines
the code path to be followed? Currently there are are many checks for a valid pointer
DrawingAreaImpl::m_layerTreeHost, which seems to be one the main decision point to
decide whether to forward calls to methods in AcceleratedDrawingArea or not, but it
seems that ::m_layerTreeHost is always a valid pointer despite the values used for
the environment variables... Is that correct? If it's going to be always valid, why
all the checks?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170212/df9e0982/attachment.html>