Page MenuHomePhabricator

Windows application on wine doesn't render the window properly
Closed, ResolvedPublic


Application required: wine, The Elder Scroll 4 Oblivion.

Step to reproduce:
start OblivionLauncher.exe (click on the executable or in terminal "wine OblivionLauncher.exe")

Expected Beheviour:
The window shows.

Actual beheviour:
The window open but is completly trasparent. Also the border and the bar on the top are trasparent.
However the window can be interacted with, and other elements are aware of it ()for example when using the pengins module).
No error is shown.

This beheviour happen on both my PC:
PackardBell iMedia : CPU Q6600 @2,4GHZ GPU Nvidia GT520 , 4GB DDR2 RAM
HP pavillon : CPU AMD A8 @ 2,2 Ghz, GPU R5 Integrated, GPU Radeon HD8650 Dedicated, 4GB DDR3 RAM
ArchLinux 64bit. (Tried with kernels: linux, linux-zen, linux-lts, linux-covolunablu-gaming)
Enlightenment X Session. (On a Enlightenment Wayland session the aplication is drawn correctly)
For now this is the only application that give me this issue.

llde created this task.Apr 7 2017, 7:08 AM
llde updated the task description. (Show Details)
llde updated the task description. (Show Details)Apr 7 2017, 7:11 AM
llde added projects: Restricted Project, enlightenment-git.Apr 10 2017, 2:16 AM
zmike added a subscriber: raster.Apr 10 2017, 4:37 AM

I don't have this game, you'll need to find another application which has the same issue. I suspect a driver bug though.

llde added a comment.Apr 10 2017, 5:44 AM

With two completly different computers? Considering that all others Windows Manager (gnome,kde,deepin, i3wm, ) on X session works completly fine?
(As the launcher should be the only thing needed, and it should "work enough" to investigate the bug even without the rest of the game I may send the OblivionLauncher.exe directly otherwise how can provide debugging informations?)

zmike added a comment.Apr 10 2017, 7:02 AM

You can try running enlightenment with EINA_LOG_LEVELS=e:4 and posting a log. What version are you using?

llde added a comment.Apr 11 2017, 3:17 AM

I'm getting these lines. Not sure if they are related or not:
DBG<551>:e src/bin/e_comp_x.c:1563 _e_comp_x_reparent() == repar [2100861] to [2100880]
DBG<551>:e src/bin/e_comp_x.c:2311 _e_comp_x_message() missed client message 'WM_PROTOCOLS' for 2100861 (This is the only line that in a wayland session I don't have)
DBG<551>:e src/bin/e_comp_object.c:1715 _e_comp_intercept_show_helper() [0x32b7190] real hid - fix

Full Stderr Log:

zmike added a comment.Apr 11 2017, 4:56 AM

I don't see anything there which could be related to the issue. 21.8 will probably happen soon, and I'll try to add some new methods for getting debug info there...

llde added a comment.Apr 11 2017, 11:32 AM

I uploaded the Oblivion Launcher:

The executable doens't require any external dll. Only wine.

(To Trigger the bug you don't need anything installed. I just extracted this launcher from the disc)

llde added a comment.EditedJul 1 2017, 5:28 AM

@zmike any news on this?

I noticed that (at least in enligthenment 21.8) if I open the application, right click on the trybar icon to open the context menu, activate Composite->Not Redirected (Non Rediretto in Italian ) option the application is drawn correctly but without the top bar

If you restart then it will probably show up, but this will take a bit longer to resolve.

jpeg added a subscriber: jpeg.Jul 27 2017, 12:06 AM

This is not related to T5678.

What happens here is that the wine Oblivion window is actually marked as invisible by setting opacity = 0. And then everything goes wrong.

  1. The window has an XAtom for a split second for _NET_WM_WINDOW_OPACITY and its value is 0.

This is found at e_comp_x.c:

 if (ec->netwm.fetch.opacity)
      unsigned int val;

      if (ecore_x_window_prop_card32_get(win, ECORE_X_ATOM_NET_WM_WINDOW_OPACITY, &val, 1) > 0)
           val = (val >> 24);
           if (ec->netwm.opacity != val)
                ec->netwm.opacity = val;
                rem_change = 1;

One call is valid and returns val = 255.
Btw this code should probably use ecore_x_netwm_opacity_get().

  1. All subsequent calls fail, as the window does not have the XAtom anymore. It's simply removed, and never appears with xprop.
  1. When the call fails, no action is taken. So once the opacity has been set to 0 (which was "valid" at that time), it is never reset to 255 later.

I've added this workaround:

if (ecore_x_window_prop_card32_get(win, ECORE_X_ATOM_NET_WM_WINDOW_OPACITY, &val, 1) > 0)
     val = (val >> 24);
     if (ec->netwm.opacity != val)
          ec->netwm.opacity = val;
          rem_change = 1;
else if (ec->netwm.opacity != 255)
     ec->netwm.opacity = 255;
     ec->changes.visible = 1;
     rem_change = 1;

This is "good", but not enough.

  1. The call to show() happens as expected in e_client_idler_before():
     if (ec->ignored) continue;
     // pass 2 - show windows needing show
     if ((ec->changes.visible) && (ec->visible) &&
         (!ec->new_client) && (!ec->changes.pos) &&
          evas_object_show(ec->frame); // YES!!!
          ec->changes.visible = !evas_object_visible_get(ec->frame);

But it leads to:

  1. _e_comp_intercept_show() does not reset the opacity on the window, because it takes the true path in:
if (cw->effect_obj)
  1. We never reach the code that set the color initially, which was in _e_comp_intercept_show():
evas_object_color_set(cw->clip, ec->netwm.opacity, ec->netwm.opacity, ec->netwm.opacity, ec->netwm.opacity);

The only time we reach this point, opacity is 0.

  1. The clipper is "invisible" from Evas point of view. This is correct behaviour from Evas. E needs to check and reset the opacity "somehow".
jpeg added a comment.Jul 27 2017, 12:50 AM

Hm it seems that there is an issue where we never receive a property change event when this property is changed, and so the update doesn't happen. I've done some workarounds for it which seem to solve the issue...