Call `glViewport()` once when initializing the backend with the maximum
supported dimensions. Since all shaders are equipped with the
corresponding projection matrix, the viewport does not have to be
updated prior to each draw call.
Related: a7bd48f5ab
Set viewport in `gl_average_texture_color()` to global `vp_width` and
`vp_height` as the projection matrix has been initialized to these dimensions
as well.
Related: a7bd48f5ab
- Query maximum supported dimensions of `glViewport()` when initializing
so we don't have to worry about differently sized textures when
rendering (usually the same as the maximum supported texture size, but
dependend on the driver).
- Set projection matrix in all shaders at startup to queried viewport
dimensions. Allows using screen coordinates for all vertex positions
without having to keep track of framebuffer dimensions.
- Follow recommendations and set `glViewport()` to queried maximum dimensions
for each draw call (`glDraw*()`, `glClear()`).
Related: #349
xrender-sync-fence might be enabled after init because of driver
detection. Instead of creating it on demand, just always create it as
this is simpler.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
We use the __GL_YIELD=usleep workaround when we detect the NVIDIA
driver, so we could use glFinish without the NVIDIA driver taking all
the CPU.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Because it needs to be cleared when we reset, so we don't use a freed
fbconfig across reset.
Related: #381
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
GLX context is not destroyed immediately after calling
glXDestroyContext. It is only destroyed when it's no longer
being used. So make sure to release the context
Fixes#381
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Flags might be cleared on a destroyed window, if it's set because of an
event received before the window is destroyed.
Eventually we want to delay the handling of destroy notify as well.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Mark it CLIENT_STALE and clear the client instead of recheck it
immediately. It's better to recheck when we have the server grabbed.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make sure the window struct is indeed destroyed and freed when a window
is reparented away from root. So we won't find it later and get
confused.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Don't just mark it as CLIENT_STALE. To make sure we don't later find the
old frame window as the frame of the client.
Fix assertion failure in ev_destroy_notify.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
win_on_factor_change is called when client window changed for a frame,
in that case, the mode of the window could change.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This reverts commit 04fe4a76b2.
This brings back the previous incomplete fix attempt for #299. See the
commit message of the revert for why it's incomplete.
A different fix is then attempted, see commit xxxxxxx for how that fix
works.
However, the second fix is incomplete by itself as well. The reason is
that i3 reparent the real window to the frame first, before destroying
the placeholder client of that frame. So briefly, that frame would have
2 client windows. And the frame is mapped before the placeholder is
destroyed. So even though we only call win_recheck_client when/if the
frame window is mapped, it can still be called when there are 2 client
windows, it would pick up the wrong client window in that case.
So what we need is to combine both fixes.
The second fix makes sure we are up to date on the client window
information when we starts to listen for events on the frame window;
while the first fix would keep us up to date afterwards.
This revert also includes a fix for assertion failure raised in #371
See #299 for root cause of the bug.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of handling reparent notify on the spot by updating the client
windows, setup a flag on the window and call win_recheck_client later.
This makes handling of complex scenarios easier. As example, see the
case in issue #299.
Note this is not a complete fix for #299
Handle more (hopefully all) edge-cases when updating `opacity_target_old`:
* `MAPPING` transitions to `FADING` if new target is reached. Otherwise
no update.
* `FADING` clamps to current `opacity` if old target is too small.
* `UNMAPPING`/`DESTROYING` clamps to current `opacity` if old target is
too small.
* Add new field `opacity_target_old` to `struct managed_win` for
tracking relevant `opacity_target` changes.
* Smoothly fade blur-texture opacity on window opacity changes (based on
window opacity), when the window was or will be fully transparent
(`w->opacity ~< 0.004`).
* Fixed alpha-clipping of the blur-texture when using `inactive-opacity` or
repeatedly setting window opacity with large fade intervals (should fix#314).
These two flags are intended for subtly different things. I can probably
justify the distinction, but it's definitely difficult to explain. And
there is no obvious benefits to keep them separate.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Bernd Busse