Bug 168128

Also, I tried the following: - Resizing the Epiphany/MiniBrowser window does not seem to trigger repaints. With AC disabled (either because it does not get enabled on-demand, or disabled with the environment variable), the “contents” of the blank webview show some flickering. - I have also updated to WebKitGTK+ 2.14.4 in my old laptop, also running Arch Linux. Painting works normally in that one. The OS setups are about the same, the main difference being the hardware. I'll try and post what is exactly different, as it seems that could help out identifying the root cause of the issue.

Created attachment 301173 [details] xdpyinfo for current laptop (failing, Intel HD Graphics 520)

Created attachment 301174 [details] xdpyinfo for old laptop (working, Intel Haswell-ULT Graphics)

The most obvious difference is that in my old laptop I got DRI3 disabled at some point (using “Option "DRI" "2"” in a xorg.conf.d snippet). Disabling DRI3 with the environment variable did not solve the issue: % LIBGL_DRI3_DISABLE=1 Tools/Scripts/run-minibrowser --gtk --debug # Still blanks Editing “/etc/X11/xorg.conf.d/99-intel.conf” and adding the option there to disable DRI3, and launching a new X session makes WebKitGTK+ paint webviews correctly without having to set any environment variable. For reference, these are the contents of that file in my system: % cat /etc/X11/xorg.conf.d/99-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "DRI" "2" # Added for testing. Option "Backlight" "intel_backlight" EndSection With the configuration snippet above, non-AC mode works.

Well crap!

I'm surprised DRI setting affects the non AC mode.

I have the same issue on Arch Linux with 2.14.4, pretty annoying because evolution does not render emails. Setting WEBKIT_FORCE_COMPOSITING_MODE=1 does NOT work for me. DRI is set to 3 in Xorg config.

(In reply to comment #7) > Setting WEBKIT_FORCE_COMPOSITING_MODE=1 does NOT work for me. > DRI is set to 3 in Xorg config. Because evolution sets WEBKIT_DISABLE_COMPOSITING_MODE. It should not do that.

*** Bug 168180 has been marked as a duplicate of this bug. ***

Created attachment 301303 [details] 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?

(In reply to comment #9) > *** Bug 168180 has been marked as a duplicate of this bug. *** Ah, good catch, I forgot to mention that I have HiDPI here as well. So the issue seems to be manifest itself in HiDPI+DRI3.

For comparison, output with HiDPI disables (scale-factor==1): % WEBKIT_DISABLE_COMPOSITING_MODE=1 run-minibrowser --gtk --debug Starting MiniBrowser. DrawingAreaImpl: instantiated! updatePreferences AC enabled: no AC forced: no layerTreeHost: 0x7fce46674fdd updateBackingStoreState m_forceRepaintAfterBackingStoreStateUpdate: no setNeedsDisplay setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay setNeedsDisplayInRect continuing -> scheduleDisplay() ... (repeats a few times) ... scheduleDisplay setNeedsDisplayInRect dirty.isEmpty() -> early return mainFrameContentSizeChanged setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay didUpdateBackingStoreState setNeedsDisplay setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay sendDidUpdateBackingStoreState display shouldPaintBoundsRect setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay displayTimerFired display display shouldPaintBoundsRect didUpdate displayTimerFired display display: empty dirty region -> early return setNeedsDisplayInRect continuing -> scheduleDisplay() scheduleDisplay setNeedsDisplayInRect continuing -> scheduleDisplay() ...

Note how, with HiDPI disabled, m_layerTreeHost==nullptr when control flow reaches DrawingAreaImpl::mainFrameContentSizeChanged() because the print-debug “m_layerTreeHost -> delegating” is not logged. I wonder what causes m_layerTreeHost to be a valid pointer with HiDPI+DRI3, but it certainly seems to be the crux of this issue.

Just to confirm the relevance... I have also HiDPI here.

This has nothing to do with DRI3, the only problem is the device scale factor.

Created attachment 301335 [details] Patch

(In reply to comment #15) > This has nothing to do with DRI3, the only problem is the device scale > factor. Right, I forgot to mention that my old laptop, apart from having DRI3 disabled, does _not_ have a HiDPI screen. I built WebKitGTK+ locally with your patch applied, and I can confirm that MiniBrowser correctly paints websites now, both using 1x and 2x scale-factor. Tested with all the combinations of environment variables: % run-minibrowser --gtk --debug # No environment varible. % WEBKIT_DISABLE_COMPOSITING_MODE=1 run-minibrowser --gtk --debug % WEBKIT_FORCE_COMPOSITING_MODE=1 run-minibrowser --gtk --debug So informal r+ from me — now that I see what it does, it makes sense. - - - - - Side question: is there some way in which we could avoid this kind of regression in the future? It would be interesting to do some automated smoketesting, like building and loading a few selected websites with MiniBrowser under the control of a script, capturing the screen, and checking that there are non-blank pixels on a capture of the window, for different scale-factors and AC/non-AC modes.

(In reply to comment #17) > (In reply to comment #15) > > This has nothing to do with DRI3, the only problem is the device scale > > factor. > > Right, I forgot to mention that my old laptop, apart from having DRI3 > disabled, does _not_ have a HiDPI screen. > > I built WebKitGTK+ locally with your patch applied, and I can confirm > that MiniBrowser correctly paints websites now, both using 1x and 2x > scale-factor. Tested with all the combinations of environment variables: > > % run-minibrowser --gtk --debug # No environment varible. > % WEBKIT_DISABLE_COMPOSITING_MODE=1 run-minibrowser --gtk --debug > % WEBKIT_FORCE_COMPOSITING_MODE=1 run-minibrowser --gtk --debug > > So informal r+ from me — now that I see what it does, it makes sense. > > - - - - - > > Side question: is there some way in which we could avoid this kind of > regression in the future? It would be interesting to do some automated > smoketesting, like building and loading a few selected websites with > MiniBrowser under the control of a script, capturing the screen, and > checking that there are non-blank pixels on a capture of the window, for > different scale-factors and AC/non-AC modes. We should enable hidpi layout tests.

Committed r212228: <http://trac.webkit.org/changeset/212228>