Closed Bug 1589512 Opened 2 years ago Closed 2 years ago

Add OS compositor interface to webrender

Categories

(Core :: Graphics: WebRender, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: gw, Assigned: gw)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

No description provided.
Assignee: nobody → gwatson
Attachment #9101981 - Attachment is obsolete: true

I've written a patch to hook it up to NativeLayers. Seems to work ok!
Partial tile repainting is obviously broken, I haven't hooked up clips so it renders wrong, vibrancy is broken (as expected), and it's pretty slow. It seems to be repainting four tiles during scrolling even on simple pages. Sometimes it tries to delete surfaces that don't exist. My window ends up with 121 layers, which seems like it's too much.

Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/93e786c07786
Part 1 - Add OS compositor interface to webrender. r=kvark,mstange
Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e6cd2b2207bd
Part 2 - Add example DirectComposite webrender integration. r=kvark
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

:gw, gecko uses EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE in GetAndInitDisplayForWebRender(). It makes rendering upside down. But com_dc_create_window() seems not use it. Then overlay rendering becomes upside down with WR compositor on Windows. Is there a reason for the change?

Flags: needinfo?(gwatson)

I originally had that in the sample but removed it since everything was upside down. Perhaps it's not necessary when drawing into the DC surface API (not the swapchain API) since the surfaces are considered off-screen buffers?

I didn't actually check if ANGLE is doing extra work in the example without that flag, but it may just not be necessary when drawing straight into DC surfaces?

Flags: needinfo?(gwatson)

On Windows, we already use "DC Visual + SwapChain". From Bug 1585893, "DC Visual + DCompositionSurface" seems to work as similar coordinate to the SwapChain usage. In WR, there is a code to do Y-flip for frame buffer. Is it related to the y-flip difference?

I checked example-compositor sample. When compositor was disabled, both with and without EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE cases, rendering results were same. If there is no EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE , copy happens at SwapChain11::swapRect(). If EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE is used, copy did not happen at SwapChain11::swapRect().

EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE was necessary when SwapChain was created by ANGLE. Current gecko does not request ANGLE to create a swap chain. Instead gecko creates SwapChain. Then we need to re-check if EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE is necessary for gecko.

With current ANGLE , it seems better to use EGL_SURFACE_ORIENTATION_INVERT_Y_ANGLE instead of EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE if it is necessary. Chromium uses EGL_SURFACE_ORIENTATION_INVERT_Y_ANGLE.

Blocks: 1536360
You need to log in before you can comment on or make changes to this bug.