Can we dergrade the performance of the xrender backend?

[yshui]

I am willing to maBke xrender backend less performant if that means we could simplify the codebase.

One example I have right now is that, if we make use of the depth buffer in OpenGL, we could ditch the whole reg_ignore logic, potential removing up to 1k loc. But that would also make xrender slower, because there is no depth testing capability there.

Is this worth it? I'd like to hear what the users think. I hope there are many users who are forced to use xrender.

[yshui]

cc @tryone144

[phisch]

To be honest, why provide an xrender backend in the first place? Drop it, focus on GL, clean up the code as much as possible while providing one solid and clean backend.

[tryone144]

If I understand correctly, the reg_ignore logic tries to minimize the number of pixels we have to render with each update. In particular keeping track of what part of a window is actually visible and only rendering that part.
This becomes less useful once you have very few windows actually overlapping by much or most of your windows are not fully opaque as you have to render the whole window anyways. Or am I missing something here?

I don't think we should drop the xrender backend completely as I am sure there are some users who benefit from it. However, the xrender backend should not become a burden to the glx backend with (questionable) performance hacks.

One example I have right now is that, if we make use of the depth buffer in OpenGL, we could ditch the whole reg_ignore logic…

@yshui Can you elaborate on how we could utilize the depth buffer? Aren't we drawing from back-to-front currently for transparency?

[yshui]

@tryone144 it's possible to do a depth only pass first to create the depth buffer. we can make it so pixels with alpha < 1 don't update the depth value. this combined with early depth testing should get us performance very close to what we have now.

it's kind of like off-loading the region operations to GPU.

[frebib]

How much slower? 50%? less?