Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Window Border Artifact #77

Closed
baskerville opened this issue Jan 7, 2013 · 4 comments
Closed

Window Border Artifact #77

baskerville opened this issue Jan 7, 2013 · 4 comments

Comments

@baskerville
Copy link

In the following screenshot:
http://ge.tt/15VJnNB/v/62

Two terminal windows can be seen, with an artifact on the right and bottom sides of the left window. They have been spawn in a tiling WM, in monocle mode, with a border width of 0, and then the mode was changed to tiled (i.e. border width > 0).

In fact, I can make the artifact appear (non systematically) with just one window by toggling the tiling layout from monocle to tiled.

I've launched compton with:

compton -bc -t -8 -l -9 -r 6 -o 0.7
@richardgv
Copy link
Collaborator

  1. The boring thing firstly, make sure you are using the latest version. (Preferably, the latest build from richardgv-dev branch.)
  2. Are you using your own window manager (bspwm?), or another one? Could you please provide more detailed instructions on how to reproduce the problem?
  3. By "border width" are you talking about the border_width in X window attributes, or the border created with "border/frame windows", like how most window managers add frames to windows? compton possibly handles the X window attribute border_width poorly, because I've never seen a window with a.border_width > 0.
  4. Does compton configuration affect the problem? Does the problem appear if you run compton with compton --config /dev/null?
  5. Does the window has a bounding shape, added with X Shape extension? Is it an ARGB window?

By the way, I still have no finished, huh, debugging, the generic window matching mechanism you requested. Need an unpredictable period of time before I could push it out. Sorry.

@baskerville
Copy link
Author

  1. Yes, it happens with your branch too.
  2. It happens in bspwm and I just realized that it only happens when the following setting is true: borderless_monocle. So it seems that compton doesn't appreciate the modification of the window border width from 0 to something > 0.
  3. I'm talking about the basic X border (I'm drawing the triple borders in the border pixmap).
  4. Yes, the problem is still there.
  5. No, just a regular window.

@richardgv richardgv mentioned this issue Jan 9, 2013
Closed
richardgv added a commit that referenced this issue Jan 9, 2013
@richardgv
Bug fix #77 incorrect border_width handling & #73 window data issue
7188054 
- (Hopefully) fix all incorrect handling of w->a.border_width in compton
  (#77). Thanks to baskerville for reporting.

- Attempt to fix #73 by correcting a mistake that window data is fetched
  from the wrong function. Thanks to zakkak.

- Add git commit/tag detection to Makefile for automatic versioning.

- Change -lGL linking order, to fix a segmentation fault caused by
  something in nvidia-drivers under FreeBSD, mentioned in #74. Thanks
  for the report from DachiChang.

- Link to -levent_core instead of -levent in Makefile. We might move to
  libev soon, though.

- Increase SWOPTI_TOLERANCE to handle the extraordinary delay of
  kqueue() under FreeBSD. Thanks for DachiChang's report.

- Add helper function dump_drawable() for debugging.

- Replace XInternAtom() calls with get_atom().

- Remove -lrt as it's unneeded.
@richardgv
Copy link
Collaborator

Thanks for the report. I could reproduce it. I hope 7188054 (in richardgv-dev branch right now) fixes the problem. If there are any remaining issues related to border_width, please report to us with detailed instructions to reproduce it.

@baskerville
Copy link
Author

It seems to be fixed, thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@baskerville @richardgv