Author Topic: Workarounds for Z-order and movement issues in Linux/Wine?  (Read 1286 times)

tails__

  • Posts: 16
Preface: I understand all too well that XMPlay was never made to be used under POSIX enviroment and I am not asking to port it to Linux, however I do ponder if it's about time we thought of some kind of solution to the issue at hand, given somewhat growing Linux userbase these days. And I've been personally using XMPlay under wine for well over 10 years, so I have some amount of personal interest in the issue.

That being said, I'd like to document this issue to uttermost of my ability, so perhaps it will be possible to provide some kind of fix.

So, there seem 2 separate but close issues:

1. For skins that use sliding panels OR overlapping elements, these elements are rendered in the order their sub-windows regardless of their intending Z-order. Moreover clicking on these items bring them to top regardless (see attachment 1). Also, when moving main window it can be seen that sub-elements lag behind the main window a bit.

2. For not yet completely understood reason when moving XMPlay window, its sub-elements (including extended playlist/info window) begin to fly around screen as if trying to keep up with main window (they seem to follow the direction of moving main window, but when they reach its position the main window jumps again in the same direction it was moved it). This is a thing that begins and ends abruptly, so restarting a player does not help.

Now, I believe both issues are closely related to how X11 server manages its window objects, how Wine translates that to and from WinAPI, and finally how sub-element movement and position is implemented in XMPlay itself.

For issue "1" I didn't manage to find a workaround: It persist regardless of window manager, decorations or virtual desktop enabled. It might just be something hardcoded into Wine, OR XMPlay manipulates sub-item z-order on the fly, which just so happen to be edge case and fail to work in timely fashion under Wine/X11.

For issue "2" there is workaround: you disable window manager control over wine completely, and then issue disappears. This is however not the best workaround as now the window does not behave together with system being always on top, not visible to task panel (so tray icon must be enabled to not lose window) and being immovable with shortcuts/Alt-drag.

So the issue 2 is closely related to when sub-element position is updated, because this is accounted for by window managers as they, maybe, try to restore element position if it's updated too quickly and perhaps causing a race condition which also manifests only from time to time. I can confirm this with openbox and xfwm window managers with their base configurations, I've also seen similar reports from people using KDE and Gnome desktops.

Given this,

1. How feasible it is to "flatten" the player GUI, so only single player window and info windows are created? This basically means interface is rendered synchronously in software in known order, and z-order issue is thus eliminated.

2. How problematic is it to somehow monitor sub-window positions updated outside xmplay, thus perhaps locking position update until that value is unchanged? I wonder if perhaps XMPlay monitors and overwries window position attributes even if it should not generally? I can observe that forcibly moving e.g. track title element by dragging in with ALT pressed, causes other elements and the main window to be moved along as well.
« Last Edit: 14 Nov '23 - 09:40 by tails__ »

Ian @ un4seen

  • Administrator
  • Posts: 25866
1. How feasible it is to "flatten" the player GUI, so only single player window and info windows are created? This basically means interface is rendered synchronously in software in known order, and z-order issue is thus eliminated.

Recentish XMPlay updates do actually kind of do this, but only for skins that don't have panels opening left or up (supporting them too was glitchy). So it won't apply to the current default skin (panel opens left), but you could try other skins. The next default skin won't have opening panels, so it should work better under Wine. Here's the latest build:

   www.un4seen.com/stuff/xmplay.exe

2. How problematic is it to somehow monitor sub-window positions updated outside xmplay, thus perhaps locking position update until that value is unchanged? I wonder if perhaps XMPlay monitors and overwries window position attributes even if it should not generally? I can observe that forcibly moving e.g. track title element by dragging in with ALT pressed, causes other elements and the main window to be moved along as well.

XMPlay checks the Z-order and tries to correct that (if necessary) whenever it's activated, but unfortunately the corrections appear to be ignored/overridden by Wine. But the update above should make it more useable at least with some skins. Let me know if you find it isn't.

tails__

  • Posts: 16
Oh my god, I think this just fixed both of problems I was seeing for past 8 years of running XMPlay on Linux. Thank you so much!

I noticed that all sub-windows now move almost instantly with no appearing gaps, and moving them by force only make XMPlay window move after mouse release, neato!

P.S. There have been no "running around" bug so far, and I hope it won't appear anymore, but I'll write up if it happens.

piovrauz

  • Posts: 1020
Question: is it possible that th window snapping was somewhat changet on this last XMPlay build?

I use Innocuos Matte L1 S skin, and it used to snap leaving some pixels of space: now it snaps directly on the taskbar.

I kind of liked it leaving some space...

Ian @ un4seen

  • Administrator
  • Posts: 25866
Oh my god, I think this just fixed both of problems I was seeing for past 8 years of running XMPlay on Linux. Thank you so much!

Better compatibility with Wine was one of the reasons for the changes, so it's good to hear that they have fixed the problems you were having with it.

Question: is it possible that th window snapping was somewhat changet on this last XMPlay build?

Yes, skins can have varying amounts of padding in their bitmaps, so XMPlay now checks and excludes that empty space for consistency in both screen edge snapping and positioning when switching between skins (that have different padding). But here's an update that adds a "WindowSnapGap" XMPLAY.INI option to set a gap for the screen edge snapping:

   www.un4seen.com/stuff/xmplay.exe

piovrauz

  • Posts: 1020
Thanks, WindowSnapGap does what I want :)
Innocuos uses a rather big padding, and after using it for all this time I kind of missed it.