Bugzilla

> Nico, are you aware that stransky is actively working on bug 788319

I wasn't sure whether there was active work towards using EGL instead of GLX. My goal in this hacky portotype was to see if a simple change could yield some short term wins (but I am leaning towads "probably not") and help ship wr on linux+x11 quickly.

I'm definitely in favor of using EGL, but we'll probably want to get webrender enabled for some linux user before it happens.

--

I did a very quick and dirty integration of glxCopySubBuffer in https://phabricator.services.mozilla.com/D81868 to see how it works. The documentation is scarse: 

```
 void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
				    int x, int y, int width, int height );

    may be used to copy a rectangular region of the back color buffer to
    the front color buffer.  This can be used to quickly repaint 3D windows
    in response to expose events when the back color buffer cannot be
    damaged by other windows.

    <x> and <y> indicates the lower-left corner of the region to copy and
    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
    corresponds to the lower-left pixel of the window, like glReadPixels.

    If dpy and drawable are the display and drawable for the calling
    thread's current context, glXCopySubBufferMESA performs an
    implicit glFlush before it returns.  Subsequent OpenGL commands
    may be issued immediately after calling glXCopySubBufferMESA, but
    are not executed until the copy is completed.
```

This seems to imply a model where we don't swap between buffers, we'd only copy from the back buffer to either a front buffer for the window (implying double buffering, wouldn't work with triple buffering or other types of swapchain)? 
If we invalidate the whole window this would mean an extra copy entirely compared to swapbuffer. It's unclear whether we can we mix swap buffer and copysubbuffer depending on the amount of damage.
I am not 100% sure I understand the part about "when the back color buffer cannot be damaged by other windows". I'm assuming that we don't need to worry when the window has its own surface as opposed to rendering directly into the screen as was customary in the earlier days of x11.

Testing this out I get some glitches, for example after scrolling, in a way that looks like glxCopySubBuffer does pretty much what the documentation says without enforcing double buffering. To make it work I suppose we would need to present with double buffering.

An alternative is to use the buffer age extension but having frame building and the renderer on separate threads makes this a bit error prone and ugly.

It looks like EGL has a cleaner API for this, split in two independent pieces: buffer_age to avoid re-rendering content and EGL_KHR_swap_buffers_with_damage to tell the window manager which parts were invalidated and reduce compositor overhead.

> Nico, are you aware that stransky is actively working on bug 788319

I wasn't sure whether there was active work towards using EGL instead of GLX. My goal in this hacky portotype was to see if a simple change could yield some short term wins (but I am leaning towads "probably not") and help ship wr on linux+x11 quickly.

I'm definitely in favor of using EGL, but we'll probably want to get webrender enabled for some linux user before it happens.

--

I did a very quick and dirty integration of glxCopySubBuffer in https://phabricator.services.mozilla.com/D81868 to see how it works. The documentation is scarse: 

```
 void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
				    int x, int y, int width, int height );

    may be used to copy a rectangular region of the back color buffer to
    the front color buffer.  This can be used to quickly repaint 3D windows
    in response to expose events when the back color buffer cannot be
    damaged by other windows.

    <x> and <y> indicates the lower-left corner of the region to copy and
    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
    corresponds to the lower-left pixel of the window, like glReadPixels.

    If dpy and drawable are the display and drawable for the calling
    thread's current context, glXCopySubBufferMESA performs an
    implicit glFlush before it returns.  Subsequent OpenGL commands
    may be issued immediately after calling glXCopySubBufferMESA, but
    are not executed until the copy is completed.
```

This seems to imply a model where we don't swap between buffers, we'd only copy from the back buffer to a persistent front buffer for the window (implying some sort of double buffering, wouldn't work with triple buffering or other types of swapchain)? 
If we invalidate the whole window this would mean an extra copy entirely compared to swapbuffer. It's unclear whether we can we mix swap buffer and copysubbuffer depending on the amount of damage.
I am not 100% sure I understand the part about "when the back color buffer cannot be damaged by other windows". I'm assuming that we don't need to worry when the window has its own surface as opposed to rendering directly into the screen as was customary in the earlier days of x11.

Testing this out I get some glitches, for example after scrolling, in a way that looks like glxCopySubBuffer does pretty much what the documentation says without enforcing double buffering. To make it work I suppose we would need to present with double buffering.

An alternative is to use the buffer age extension but having frame building and the renderer on separate threads makes this a bit error prone and ugly.

It looks like EGL has a cleaner API for this, split in two independent pieces: buffer_age to avoid re-rendering content and EGL_KHR_swap_buffers_with_damage to tell the window manager which parts were invalidated and reduce compositor overhead.