Skip to content

Commit

Permalink
Improvement: Change fading mechanism
Browse files Browse the repository at this point in the history 
- Change fading mechanism for better modularity. Remove fade queue and
  use members in struct _win to record fading data. In contrast to
  previous commits, this one actually could make the program slower (but
  very slightly, hardly noticeable if your CPU is anywhere close to AMD
  K7). As this commit changes lots of things, bugs are to be expected.

- Currently -F does not do its job. -f actually equals -fF. (While in
  the past -F equals nothing and -f is just -f.) A fix will be made
  soon. I suppose it isn't hard.

- Add a preprocessor function paint_preprocess() and move all
  preprocessing code in paint_all() to it.

- Add window flag support but currently unused.

- Add DamageNotify handling to ev_window().

- I'm considering removing HAS_NAME_WINDOW_PIXMAP = 0 support as I
  couldn't see what it is good for. Nor do I know what CAN_DO_USABLE
  does. Basically all my changes ignore these cases.
  • Loading branch information
@richardgv
richardgv committed Sep 19, 2012
1 parent e7da888 commit 778a8b1
Show file tree
Hide file tree
Showing 2 changed files with 259 additions and 287 deletions.
Loading

4 comments on commit 778a8b1

@chjj
Copy link
Owner

@chjj chjj commented on 778a8b1 Sep 20, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice. I can already see 2 very minor bugs this fixed with Awesome. It does seem to use a little bit more CPU, but that might be acceptable.

@richardgv
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does seem to use a little bit more CPU, but that might be acceptable.

I wonder how you are profiling compton. It looks really hard to profile as its resource consumption depends on user behaviors, and too much work is done on the X side.

By the way please look into #43 if you are interested. The problem sounds puzzling.

@chjj
Copy link
Owner

@chjj chjj commented on 778a8b1 Sep 20, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder how you are profiling compton. It looks really hard to profile as its resource consumption depends on user behaviors, and too much work is done on the X side.

Nothing scientific. This is just my first impression after a few minutes of using it. It might be the power of suggestion plus me staring at the cpu usage while swapping between two fading workspaces. This is really good work though. I've been running the latest commits for only a few hours now, and a lot of little annoyances that weren't worth describing before have disappeared.

@richardgv
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing scientific. This is just my first impression after a few minutes of using it. It might be the power of suggestion plus me staring at the cpu usage while swapping between two fading workspaces. This is really good work though. I've been running the latest commits for only a few hours now, and a lot of little annoyances that weren't worth describing before have disappeared.

Thanks. :-)

Unless you see more fading effects (which means more requests to X to generate alpha_pict, shadow_pict, and frame_alpha_pict), the performance impact won't be very noticeable, I bet. (Okay, and unless you are running it on Raspberry Pi, or have over one hundred windows on each workspace. :-) ) This commit removes the need to maintain a separate fading queue, but calculates opacity changes on every window in the window linked list. It at most would add 500 instructions to be executed on each paint, my guess is. Don't be too scared.

Please sign in to comment.