Rationale:
- "bug to be expected" -> "bugs to be expected". Usually the noun is plural in this expression (since more than one bug is likely to be found in the future).
- "because that seems to be unmaintained" -> "because it seems to be unmaintained". Using a demonstrative pronoun ("that") versus a personal pronoun ("it") suggests that we need to specify which of several Comptons is unmaintained.
- "features" -> "feature" and "stabilizes" -> "stabilize". The new backends are plural, should be conjugated without the trailing "s".
- "used" -> "use". The command used to launch picom has already been run. Changing to "use" indicates the command that habitually launches picom. Also changed "command line" (the interface, e.g. the prompt) to "command".
- "Rational" (adjective: based on reason) -> "Rationale" (noun: the reasons or logic that motivated an action)
- "when people searches" -> "when people search". Usually conjugated as plural [1](https://english.stackexchange.com/q/263046)
- "to solve aforementioned problems" -> "to solve the aforementioned problems". "Aforementioned" is preceded by a definite article when modifying a noun.
- "mentions to" (usually used in suggesting an 'honourable mention'/accolade regarding somebody) -> "mentions of" (instances of)
leftovers:
1) config file path. Has to implement compatibility functionalities before
we can change it.
2) links in man pages. Has to migrate the repo first.
3) _COMPTON_SHADOW, it has become a defacto standard, so we have to keep
supporting it.
4) dbus names, undecided whether we should/could change it.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
A quick search on GitHub showing the _COMPTON_SHADOW is actively being
used (most noteably, by polybar). It is not a difficult thing to support,
and it doesn't have that much runtime overhead. So remove the option
that guards this feature, make it enabled by default.
(Side note, I saw lots of people putting this option in their config
files, but this is actually a command line only option.)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Firstly, this breaks the assumption that when we redirect the screen,
all window is either mapped or unmapped, causing a assertion failure.
Secondly, if transition window into fading when the screen is not
redirected, the fading will not progress until the screen is redirected,
probably not the desired result.
Fixes#246
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Since user reports indicate it has real performance benefits.
Also add a command line flag for turning use-damage off.
Fixes#242
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Because first frame no window has their pixmap bound, which doesn't
happen in frames after the first. If a window is unmapped in that frame,
the compositor will try to render a window with no pixmap bound if
fading is enabled.
Now we keep track if we are in the first frame, and if that's the case
we skip fading in unmap/destroy.
Fixes#239, bug number 2
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This simplifies the logic a bit since we know a shadow is always bound
(if needed) when the screen is redirected.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
If a window is unmapped during the draw_callback re-run when the screen
is just redirected, that window won't get a chance to acquire a pixmap.
If fading is enabled, the compositor will try to render that window and
crash.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously all image stale flags are ignored when processing an unmapped
window. If a window gains a shadow during its fading out transition, the
shadow flag will be set, but shadow won't actually be generated, causing
a NULL pointer dereference during render.
Fixes#239
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Otherwise shadow won't get generated in next critical section, causing
NULL pointer dereference or assertion failure in next render.
Partially fixes#239
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
win_get_name _updates_ the name of the window by querying the X server,
thus potentially changes the behaviour of the compositor when logging is
turned on (e.g. we could fail to detect window name changes, because the
name was blindly updated in a logging call without handling the name change).
We shouldn't do that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
recheck_focus rejects focus of unmapped windows, so we have to make sure
pending maps of windows are processed before we call recheck_focus.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Yuxuan Shui