[Bug 43030] LINE: Window border stays on top of other windows

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Oct 17 13:00:39 CDT 2018


https://bugs.winehq.org/show_bug.cgi?id=43030

--- Comment #18 from Zachary Murray <dremelofdeath at gmail.com> ---
I saw that (#12), which is why I retested it. I am still experiencing the
problem even during normal use. I'll add a screenshot to show the chat
experience with the Settings window open. And I'm sure the forum will know
more, but with respect to this specific issue I don't think there's enough
information yet to understand exactly what's causing the issue.

Also, I *don't* see the thick borders issue. From your screenshot it looks like
the shadowing effect isn't rendering at all and is just black with no
transparency. Maybe it's a compositor issue? Did the shadows render correctly
before?

I noticed that we're currently on the same Ubuntu version (16.04) but using
different DEs (LXDE for you vs. XFCE for me). I wonder if that makes a
difference. Also just checking, but are you running Wine in desktop mode? Per
#4 and #16 I think that would fix it but haven't checked.

Update on #16 as well: running with the hack results in other undesirable
behavior, such as a blank window appearing randomly (particularly after
restoring after iconifying), and after restoring, the borders begin to render
incorrectly again, so it's not even a permanent fix.

I examined the border windows before and after this happened and found that
Wine is adding a stack mode (Above) to the window state after the restore
whereas none is set beforehand. I tried hacking this in the Wine X11 driver to
Below instead, which resulted in the border window not appearing at all. Less
annoying, but wrong.

The border window has some interesting styles applied, like WS_EX_TOPMOST. The
content window doesn't have this. If I understand what LINE is trying to do
correctly, it is constantly trying to reposition the border window and keeping
it above the contents by continually calling SetWindowPos() on the border
window with flags SWP_NOMOVE, SWP_NOSIZE, SWP_NOZORDER, and SWP_SHOWWINDOW set.

I wonder what would happen if WS_EX_TOPMOST were not applied (maybe with a
hack). The constant SetWindowPos() calls might be making Wine inadvertently
display them above everything where somehow Windows doesn't do that.

One thing I want to try is testing this with a different driver, like Android.
If it doesn't manifest there, I think it would indicate a problem in the X11
driver. If it does, I'd want to investigate the user32 windowing code.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list