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.

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

Icewm and compton bug? #183

Open
SolisX opened this issue Oct 17, 2017 · 7 comments
Open

Icewm and compton bug? #183

SolisX opened this issue Oct 17, 2017 · 7 comments
Labels
bug The issue exposes a bug.
Milestone

Comments

@SolisX
Copy link

SolisX commented Oct 17, 2017

Hello Everyone,

Don't know if this is a bug with icewm or compton. When i'm using compton with roxterm or xfce4-terminal the left,right and bottom of the frame becomes super transparent. This does not happen with xterm.

Look at the screenshot below.
screen03

@bbidulock
Copy link
Owner

I think that it is Icewm. With the corrections to ARGB visuals down to the frame, the frame is now 32 deep ARGB visual when the client is. I notice that your Roxterms are more transparent than your xterms. One reason is that roxterm uses ARGB visuals when a composite manager is present. Compton is applying normal window transparency on top of the ARGB transparency that Roxterm is providing in its visual. The problem is that I think that Icewm writes on the frame using a 24 deep RGB visual GC. There are three ways around this, have Icewm set the alpha channel when it writes to 255 (so its not clear); implement _NET_WM_OPAQUE_REGIONS which tells the the composite manager to ignore the alpha channel for the rectangles described by the property; or not draw on the frame at all, but draw on properly positioned default visual subwindows instead. Unfortunately, Icewm mixes the painting routines for frames and other windows, so I have to meter it pretty heavily just to find out where and what it writes to frames. It looks like more than just the border from your screenshot.

@bbidulock bbidulock added the bug The issue exposes a bug. label Oct 18, 2017
bbidulock referenced this issue Oct 18, 2017
From the looks of it a lot of pixmaps that are generated with the
root window depth are created and Icewm just expects frames to have
the same depth as the root window.

What will have to be done is to create a YFrameDecor window as a
child of YFrameWindow with a default visual and depth so that frame
decorations can be moved to that window.  It only needs to be placed
below all of the other children and things will display correctly.

This is non-trivial and requires creating a new class that takes over
all the graphics work of the actual frame.
@gijsbers
Copy link
Collaborator

@SolisX Should work better now I hope. There are in fact two solutions implemented. Choose by the configure --disable-gdk-pixbuf option.

@SolisX
Copy link
Author

SolisX commented Dec 27, 2017

Hello Gijsbers,

I'm getting corruption with that option.
screen01

@gijsbers
Copy link
Collaborator

That theme looks like Dark-Ice to me?
I can now reproduce the corruption for themes which have gradients for taskbuttons.
But without --disable-gdk-pixbuf they all work fine for me. You too?
So it's a yximage thing.

@SolisX
Copy link
Author

SolisX commented Dec 27, 2017

Yeah without --disable-gdk-pixbuf it works fine for me too.

@SolisX SolisX closed this as completed Dec 27, 2017
@gijsbers
Copy link
Collaborator

thx for testing and thx for the info!
we'll classify the yximage module as alpha and unfit for release
as both upscaling and downscaling are no good yet.

@SolisX
Copy link
Author

SolisX commented Dec 27, 2017

You're welcome. Thanks for fixing those issues.:)

@bbidulock bbidulock reopened this Dec 28, 2017
@bbidulock bbidulock added this to the 1.4.3 milestone Jun 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue exposes a bug.
Projects
None yet
Development

No branches or pull requests

3 participants