When trying to add source image transformation (e.g. scaling), I
realized it's ambiguous whether the mask should be applied before or
after the transformation. And after further thought, I decided it would
be better to have two separate masks, one for the source, which would be
in the source's coordinate system (i.e. before any transformation); and
one for the target.
And due to how we currently use the mask, I made the source mask an image,
and the target mask a region. Nothing is stopping us from making both a
combination of an image and a region, but we won't be using that
capability anyway.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
It has been irking me greatly for a while that we have two structs that
are basically the same thing. Let's unify them into a vec2 type.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
The command builder generates a list of backend operations needed to
render a layout.
The goal is two fold:
1. Help with backend interface transition. The command builder
generates calls of the new interface, with it we will be able to
remove the compat layer.
2. Reduce code duplication. Several places in the code need to know how
windows are rendered. We need that info to compare past and current
layouts to figure out the overall damage region; we need that info to
figure out which part of each render command is visible in the final
result, and clip out unnecessary regions; and finally we need that
info to actually render. I don't want to repeat the same code three
times. So instead we generate all the render steps at once as
commands, then operate on those commands.
Right now this function is called and the results logged, otherwise it's
not used.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
So they closely match what the new backend interface wants.
The GL backends' coordinate system is so complicated, I don't think I
ever fully understood it. Hopefully it is clearer now. I made it so all
intermediate images used in the backend all have the same coordinate
system as the X server (i.e. (0, 0) at top-left, Y down, X to the
right), only at the final present step are the coordinates flipped. Thus
reduce the number of places where Y-flipping is done.
X pixmaps are usually Y-down as well, even if they are not, the backend
should handle them fine as well (though there's no way for me to
test that). (Cloned X pixmaps will have the same coordinates as X
pixmaps, so if X pixmaps aren't Y-down, there will also be some
complications there. But we will get rid of image cloning in the new
interface, so it's OK).
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
And improve some of the log messages. Like, when compton exits because
of unsupported options, explain which options are causing compton to
quit.
Convert some debugging messages that are guarded behind ifdef's to log_trace,
so user don't need to re-compile to enabled them.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
IANAL, but I think I am allowed to add missing copyright notices for
someone else. And I did my best job using git history to figure out who
wrote which functions. So I hope everything is fine.
Re-did the painting logic, and document it.
It is unclear to me what is the previous painting logic. But the current
one is basically this:
1. Go through all windows top to bottom, and put visible windows (not
unmapped, opacity > 0, etc) into a linked list, from bottom to top
2. Accumulate a region of ignore on each window, which is basically the
region of screen that is obscured by all the windows above current
one.
3. Paint all the visible windows from bottom to top. Subtract the region
of ignore from the painting region. If we need to paint shadow, we
subtract the body of the window from the shadow painting region too,
because we don't want shadow behind the window.
4. region of ignore is invalidated when window stack change, an
window on top moved or changed shape, when window changed between
opaque and transparent, etc.
Notes:
It is unclear whether all the different shapes of a window (extents,
noframe, border, bounding shape, etc) are calculated correctly or not.
It is unclear if window shape related events are handled correctly or
not. Need more testing.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
