Window flickering problem in XWin multiwindow mode

Window flickering problem in XWin multiwindow mode

[S.J. Luo]

Hi,

I have some EDA tools running on a Linux machine and display on my Windows
PC using xorg-server-21.1.3 XWin multiwindow mode
Sometimes the application window flickers forever for an unknown reason.
The problem became more severe after my PC upgrade to Windows10.

Googling the problem, I did not find such issue reported.
I decided to take advantage of open source nature and solve it by myself.
After re-compiling and debugging, I found a calling loop triggered.
Here I eliminate the detail of the cause. I may write later if someone requires.

Knowing the root cause, I am now able to demonstrate the issue with a small
test case as well as a patch that works for me. Both are attached below.

SL

The test case:
==============
/* Compile : gcc -o flicker2 flicker2.c -lX11 */
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void SetMax(Display *dpy, Window win, int val)
{
    XEvent xev;
    Atom wm_state  =  XInternAtom(dpy, "_NET_WM_STATE", False);
    Atom max_horz  =  XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_HORZ", False);
    Atom max_vert  =  XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_VERT", False);

    memset(&xev, 0, sizeof(xev));
    xev.type = ClientMessage;
    xev.xclient.window = win;
    xev.xclient.message_type = wm_state;
    xev.xclient.format = 32;
    xev.xclient.data.l[0] = val; // _NET_WM_STATE_ADD or _NET_WM_STATE_REMOVE
    xev.xclient.data.l[1] = max_horz;
    xev.xclient.data.l[2] = max_vert;

    XSendEvent(dpy, DefaultRootWindow(dpy), False,
SubstructureNotifyMask, &xev);
}

int main(void) {
  Display *display;
  Window win;
  XEvent X;
  int screen;

  if (!(display = XOpenDisplay(NULL)))
    exit(1);

  screen = DefaultScreen(display);
  win = XCreateSimpleWindow(display, RootWindow(display, screen), 10,
10, 100, 100, 0,
                          BlackPixel(display, screen),
WhitePixel(display, screen));
  XMapWindow(display, win);
  SetMax(display, win, 1);
  SetMax(display, win, 0);
  XSelectInput(display, win, KeyPressMask | StructureNotifyMask);

  while (1) {
    XNextEvent(display, &X);
  }
  XCloseDisplay(display);
  return 0;
}
==============


and the patch I have applied
=======================
--- a/hw/xwin/winmultiwindowwm.c
+++ b/hw/xwin/winmultiwindowwm.c
@@ -153,6 +153,9 @@ static void

 static WMMsgNodePtr PopMessage(WMMsgQueuePtr pQueue, WMInfoPtr pWMInfo);

+static Bool
+ HaveMessage(WMMsgQueuePtr pQueue, UINT msg, xcb_window_t iWindow);
+
 static Bool
  InitQueue(WMMsgQueuePtr pQueue);

@@ -319,7 +322,6 @@ PopMessage(WMMsgQueuePtr pQueue, WMInfoPtr pWMInfo)
     return pNode;
 }

-#if 0
 /*
  * HaveMessage -
  */
@@ -331,12 +333,11 @@ HaveMessage(WMMsgQueuePtr pQueue, UINT msg,
xcb_window_t iWindow)

     for (pNode = pQueue->pHead; pNode != NULL; pNode = pNode->pNext) {
         if (pNode->msg.msg == msg && pNode->msg.iWindow == iWindow)
-            return True;
+            return TRUE;
     }

-    return False;
+    return FALSE;
 }
-#endif

 /*
  * InitQueue - Initialize the Window Manager message queue
@@ -1173,7 +1174,9 @@ winMultiWindowWMProc(void *pArg)
             break;

         case WM_WM_CHANGE_STATE:
-            UpdateState(pWMInfo, pNode->msg.iWindow, pNode->msg.dwID);
+            if(!HaveMessage(&pWMInfo->wmMsgQueue, pNode->msg.msg,
pNode->msg.iWindow))
+                UpdateState(pWMInfo, pNode->msg.iWindow, pNode->msg.dwID);
+
             break;

         default:
=======================

Re: Window flickering problem in XWin multiwindow mode

[S.J. Luo]

SL on Apr 26, 2022:

> I have some EDA tools running on a Linux machine and display on my Windows
> PC using xorg-server-21.1.3 XWin multiwindow mode
> Sometimes the application window flickers forever for an unknown reason.
> The problem became more severe after my PC upgrade to Windows10.

> After re-compiling and debugging, I found a calling loop triggered.
> Knowing the root cause, I am now able to demonstrate the issue with a small
> test case as well as a patch that works for me. Both are attached below.

Any one successfully duplicated the issue?

I minor revised the test case so it won't silently go exit on wrong DISPLAY
setting and added some comment. The running steps:

    gcc -o flicker2 flicker2.c -lX11
    /usr/bin/XWin.exe :11 -ac -multiwindow &
    DISPLAY=:11 flicker2.exe

On running, you would see a window switching rapidly between max and normal
states and never stops.

The key of triggering the window flickering(or flashing) are these two lines:

  SetWindowMax(display, win, _NET_WM_STATE_ADD);
  SetWindowMax(display, win, _NET_WM_STATE_REMOVE);

where they just set the window to be maximized and go back to normal.
Removing either of the two, the test case would become normal.
I've tried this test case on 3PCs including Windows 7 and Windows 10
and in all cases the issue happens.

This issue literally occurs on my work that runs some proprietary Linux
EDA software. I wish this can be solved on next update.

SL


flicker2.c
===================================================================
#include <X11/Xlib.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define _NET_WM_STATE_REMOVE        0
#define _NET_WM_STATE_ADD           1

void SetWindowMax(Display *dpy, Window win, int state)
{
    XEvent xev;
    Atom wm_state  =  XInternAtom(dpy, "_NET_WM_STATE", False);
    Atom max_horz  =  XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_HORZ", False);
    Atom max_vert  =  XInternAtom(dpy, "_NET_WM_STATE_MAXIMIZED_VERT", False);

    memset(&xev, 0, sizeof(xev));
    xev.type = ClientMessage;
    xev.xclient.window = win;
    xev.xclient.message_type = wm_state;
    xev.xclient.format = 32;
    xev.xclient.data.l[0] = state;
    xev.xclient.data.l[1] = max_horz;
    xev.xclient.data.l[2] = max_vert;

    XSendEvent(dpy, DefaultRootWindow(dpy), False,
               SubstructureNotifyMask, &xev);
}

int main(void) {
  Display *display;
  Window win;
  XEvent xev;
  int screen;

  if (!(display = XOpenDisplay(NULL))) {
    printf("Cannot open display. Please check DISPLAY environmet setting.\n");
    exit(1);
  }

  screen = DefaultScreen(display);
  win = XCreateSimpleWindow(display, RootWindow(display, screen),
        10, 10, 100, 100, 0,
        BlackPixel(display, screen), WhitePixel(display, screen));
  XMapWindow(display, win);

  // Uncomment either of the following two lines
  // and window would not go flashing
  SetWindowMax(display, win, _NET_WM_STATE_ADD);
  SetWindowMax(display, win, _NET_WM_STATE_REMOVE);

  while(1) {
    XNextEvent(display, &xev);
  }
  // It is supposed never get here
  XCloseDisplay(display);
  return 0;
}
===================================================================

Re: Window flickering problem in XWin multiwindow mode

[Mark Geisert]

Hello,

S.J. Luo wrote:
> SL on Apr 26, 2022:
> 
>> I have some EDA tools running on a Linux machine and display on my Windows
>> PC using xorg-server-21.1.3 XWin multiwindow mode
>> Sometimes the application window flickers forever for an unknown reason.
>> The problem became more severe after my PC upgrade to Windows10.
> 
>> After re-compiling and debugging, I found a calling loop triggered.
>> Knowing the root cause, I am now able to demonstrate the issue with a small
>> test case as well as a patch that works for me. Both are attached below.
> 
> Any one successfully duplicated the issue?

I've reproduced it.  That's a really annoying effect/issue you're seeing.  I've 
been waiting for the Cygwin X maintainer to respond.  I'm not familiar enough with 
X internals to know whether your patch is the most appropriate fix.

I will try to build the object you're patching, with your patch, and make that 
available to you as a workaround.  I'm assuming you haven't done that yourself 
just yet..  Give me a day or so to work it out.

..mark

Re: Window flickering problem in XWin multiwindow mode

[Mark Geisert]

Replying to myself..

> Hello,
> 
> S.J. Luo wrote:
>> SL on Apr 26, 2022:
>>
>>> I have some EDA tools running on a Linux machine and display on my Windows
>>> PC using xorg-server-21.1.3 XWin multiwindow mode
>>> Sometimes the application window flickers forever for an unknown reason.
>>> The problem became more severe after my PC upgrade to Windows10.
>>
>>> After re-compiling and debugging, I found a calling loop triggered.
>>> Knowing the root cause, I am now able to demonstrate the issue with a small
>>> test case as well as a patch that works for me. Both are attached below.
>>
>> Any one successfully duplicated the issue?
> 
> I've reproduced it.  That's a really annoying effect/issue you're seeing.  I've 
> been waiting for the Cygwin X maintainer to respond.  I'm not familiar enough with 
> X internals to know whether your patch is the most appropriate fix.
> 
> I will try to build the object you're patching, with your patch, and make that 
> available to you as a workaround.  I'm assuming you haven't done that yourself 
> just yet..  Give me a day or so to work it out.

I may have misread your post.  It now seems to me you've built an X server with 
your patch for your own use; you were just needing some acknowledgement from the 
Cygwin folks of the issue you reported.

In any case, anybody else who runs into the flickering window issue and needs a 
workaround, you can pick up a patched X Window server (64-bit) that I've placed in 
a public location:  http://maxrnd.com/~mark/cygwin/x86_64/XWin.exe .
Cheers,

..mark

Re: Window flickering problem in XWin multiwindow mode

[Jon Turney]

On 26/04/2022 04:53, S.J. Luo wrote:

> I have some EDA tools running on a Linux machine and display on my Windows
> PC using xorg-server-21.1.3 XWin multiwindow mode
> Sometimes the application window flickers forever for an unknown reason.
> The problem became more severe after my PC upgrade to Windows10.
> 
> Googling the problem, I did not find such issue reported.
> I decided to take advantage of open source nature and solve it by myself.
> After re-compiling and debugging, I found a calling loop triggered.
> Here I eliminate the detail of the cause. I may write later if someone requires.
> 
> Knowing the root cause, I am now able to demonstrate the issue with a small
> test case as well as a patch that works for me. Both are attached below.

Thanks very much for taking the time to look into this, and writing a patch.

I will apply it.

But I'd like to add a bit more commentary, which perhaps you can supply, 
about the analysis you did to determine:

1. how the code is misbehaving
2. how this change remedies that
3. how this change doesn't effect anything else

What your fix does is examine the queue of pending WM messages to 
determine if there are any more pending for the window receiving a 
WM_WM_CHANGE_STATE message, and if there are, ignore it.

It seems to me that is error prone, in a couple of ways:

1. it should check the message type as well, as e.g. a pending message 
of a different type could cause a WM_WM_CHANGE_STATE message to be ignored.

2. even then, assuming that successive WM_WM_CHANGE_STATE messages 
cancel out each other isn't always true e.g. consider a sequence of 
_NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT followed by 
_NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ.


If you were to send other patches in future, please send them as 
attachments, or even better, using git format-patch/git send-email, as 
that makes it much easier to apply them without white-space damage and 
with correct attribution.

Re: Window flickering problem in XWin multiwindow mode

[S.J. Luo]

[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]

Hi,

> > > I have some EDA tools running on a Linux machine and display on my Windows
> > > PC using xorg-server-21.1.3 XWin multiwindow mode
> > > Sometimes the application window flickers forever for an unknown reason.
> > > The problem became more severe after my PC upgrade to Windows10.
> > >
> > > Knowing the root cause, I am now able to demonstrate the issue with a small
> > > test case as well as a patch that works for me. Both are attached below.
> >
> > Thanks very much for taking the time to look into this, and writing a patch.
> > But I'd like to add a bit more commentary, which perhaps you can supply,
> > about the analysis you did to determine:
> >
> > 1. how the code is misbehaving
> > 2. how this change remedies that
> > 3. how this change doesn't effect anything else
> >
> > What your fix does is examine the queue of pending WM messages to
> > determine if there are any more pending for the window receiving a
> > WM_WM_CHANGE_STATE message, and if there are, ignore it.
> >
> > It seems to me that is error prone, in a couple of ways:
> >
> > 1. it should check the message type as well, as e.g. a pending message
> > of a different type could cause a WM_WM_CHANGE_STATE message to be ignored.
> >
> > 2. even then, assuming that successive WM_WM_CHANGE_STATE messages
> > cancel out each other isn't always true e.g. consider a sequence of
> > _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT followed by
> > _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ.
> >

> Here I have some details on the problem:
> In following, WWCS means WM_WM_CHANGE_STATE
> There exists a message self-generating loop
> I.e., a WWCS message may generate another WWCS.
>
> winSendMessageToWM(WWCS) --> MultiWindowWMProc(WWCS)
> --> UpdateState() --> ShowWindow() --> MultiWindowProc(WM_SIZE)
> --> winAdjustXWindowState() --> winSendMessageToWM(WWCS)
>
> In normal case, there is a conditional code inside UpdateState() that
> could break the loop.
>
>             if (current_state == state)
>                 return;
>
> Normally after maximizing the window, the WWCS just
> to be self-generated once. On processing the 2nd WWCS,
> the current window state matches WWCS target state
> and ShowWindow() won't be called and the loop could end.
>
> Initial
>     Window state normal
>     queue : | WWCS(max1) |
> --> process WWCS(max1) :
>     Winow state (norm) != target state (max2)
>     Set Window state to max and generate WWCS(max2)
>     queue : | WWCS(max2) |
> --> Process WWCS(max2) :
>     Winow state (max) == target state (max)
>     break
>
> where WWCS(max1) means WWCS msg with target state max
> and 1 means first generated/inserted WWCS in queue.
>
> However, there is case triggering this loop running forever.
> Assuming intitially there are two WWCS message exists
> where one is to maximize window and one is to normal window
> The condition of state compare in UpdateState() would never match.
> And WWCS(max) and WWCS(norm) is going to self-generate in turn.
>
> Initial
>     Window state normal
>     queue : | WWCS(max1) | WWCS(norm1) |
> --> process WWCS(max1)
>     Winow state (norm) != target state (max)
>     Set window state to max and generate WWCS(max2)
>     queue : | WWCS(norm1) | WWCS(max2) |
> --> Process WWCS(norm1)
>     Winow state (max) != target state (norm)
>     Set window state to norm and generate WWCS(norm2)
>     queue : | WWCS(max2) | WWCS(norm2) |
> --> Process WWCS(max2)
>     Winow state (norm) != target state (max)
>     Set window state to max and generate WWCS(max3)
>     queue : | WWCS(norm2) | WWCS(max3) |
> --> Process WWCS(norm2)
>     Winow state (max) != target state (norm)
>     Set window state to norm and generate WWCS(norm3)
>     queue : | WWCS(max3) | WWCS(norm3) |
> :
> (loop forever)
>

I just did some more study on the code of multiwindow window manager and
X11 Window Properties as well as the questions you brought up.

The first question :

> it should check the message type as well, as e.g.
> a different type mesage could cause WM_WM_CHANGE_STYLE to be ignored.

Not sure what the "type" of a message means.
Do you mean window manager message WM_xxxxx that is processed by
winMultiWindowWMProc() where it is alreadychecked in HaveMessage(),
or do you mean X message XCB_xxxxxx that is processed by
winMultiWindowXMsgProc()?
Maybe you can provide an example of another message type?

The second question:

> Successive WM_WM_CHANGE_STATE messages cancel out each other
> isn't always true ex. _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT
> followed by _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ.

Inspecting the code that deal with XCB_CLIENT_MESSAGE, it seems already
true before the patch: The window goes maximized only if X client do one
_WM_STATE_ADD action with _NET_WM_STATE_MAXIMIZED_VERT and
_NET_WM_STATE_MAXIMIZED_HORZ simultaneously specified. Otherwise,
the WM_WM_CHANGE would not be sent to the queue.
Further, in UpdateWindowState(), the state and related X properties are
either all-overwritten or all-skipped.
There seems to be no state property half-update case if we skip
UpdateWindowState().

In anyway, I just came out somewhat different patch attached.
Where it just skips the Win32 ShowWindow() call instead of
skipping processing WM_WM_CHANGE_STATE. It might be better because
the X properties are still always updated in each in WM_WM_CHANGE_STATE.
Maybe you could provide further comment.

SL

[-- Attachment #2: flicker2b.patch --]
[-- Type: application/x-patch, Size: 4634 bytes --]

Re: Window flickering problem in XWin multiwindow mode

[Jon Turney]

On 07/05/2022 03:01, S.J. Luo wrote:
> Hi,
> 
>>>> I have some EDA tools running on a Linux machine and display on my Windows
>>>> PC using xorg-server-21.1.3 XWin multiwindow mode
>>>> Sometimes the application window flickers forever for an unknown reason.
>>>> The problem became more severe after my PC upgrade to Windows10.
>>>>
>>>> Knowing the root cause, I am now able to demonstrate the issue with a small
>>>> test case as well as a patch that works for me. Both are attached below.
>>>
>>> Thanks very much for taking the time to look into this, and writing a patch.
>>> But I'd like to add a bit more commentary, which perhaps you can supply,
>>> about the analysis you did to determine:
>>>
>>> 1. how the code is misbehaving
>>> 2. how this change remedies that
>>> 3. how this change doesn't effect anything else
>>>
>>> What your fix does is examine the queue of pending WM messages to
>>> determine if there are any more pending for the window receiving a
>>> WM_WM_CHANGE_STATE message, and if there are, ignore it.
>>>
>>> It seems to me that is error prone, in a couple of ways:
>>>
>>> 1. it should check the message type as well, as e.g. a pending message
>>> of a different type could cause a WM_WM_CHANGE_STATE message to be ignored.
>>>
>>> 2. even then, assuming that successive WM_WM_CHANGE_STATE messages
>>> cancel out each other isn't always true e.g. consider a sequence of
>>> _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT followed by
>>> _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ.
>>>
> 
>> Here I have some details on the problem:
>> In following, WWCS means WM_WM_CHANGE_STATE
>> There exists a message self-generating loop
>> I.e., a WWCS message may generate another WWCS.
>>
>> winSendMessageToWM(WWCS) --> MultiWindowWMProc(WWCS)
>> --> UpdateState() --> ShowWindow() --> MultiWindowProc(WM_SIZE)
>> --> winAdjustXWindowState() --> winSendMessageToWM(WWCS)
>>
>> In normal case, there is a conditional code inside UpdateState() that
>> could break the loop.
>>
>>              if (current_state == state)
>>                  return;
>>
>> Normally after maximizing the window, the WWCS just
>> to be self-generated once. On processing the 2nd WWCS,
>> the current window state matches WWCS target state
>> and ShowWindow() won't be called and the loop could end.
>>
>> Initial
>>      Window state normal
>>      queue : | WWCS(max1) |
>> --> process WWCS(max1) :
>>      Winow state (norm) != target state (max2)
>>      Set Window state to max and generate WWCS(max2)
>>      queue : | WWCS(max2) |
>> --> Process WWCS(max2) :
>>      Winow state (max) == target state (max)
>>      break
>>
>> where WWCS(max1) means WWCS msg with target state max
>> and 1 means first generated/inserted WWCS in queue.
>>
>> However, there is case triggering this loop running forever.
>> Assuming intitially there are two WWCS message exists
>> where one is to maximize window and one is to normal window
>> The condition of state compare in UpdateState() would never match.
>> And WWCS(max) and WWCS(norm) is going to self-generate in turn.
>>
>> Initial
>>      Window state normal
>>      queue : | WWCS(max1) | WWCS(norm1) |
>> --> process WWCS(max1)
>>      Winow state (norm) != target state (max)
>>      Set window state to max and generate WWCS(max2)
>>      queue : | WWCS(norm1) | WWCS(max2) |
>> --> Process WWCS(norm1)
>>      Winow state (max) != target state (norm)
>>      Set window state to norm and generate WWCS(norm2)
>>      queue : | WWCS(max2) | WWCS(norm2) |
>> --> Process WWCS(max2)
>>      Winow state (norm) != target state (max)
>>      Set window state to max and generate WWCS(max3)
>>      queue : | WWCS(norm2) | WWCS(max3) |
>> --> Process WWCS(norm2)
>>      Winow state (max) != target state (norm)
>>      Set window state to norm and generate WWCS(norm3)
>>      queue : | WWCS(max3) | WWCS(norm3) |
>> :
>> (loop forever)
>>

Thanks for providing this analysis.

> 
> I just did some more study on the code of multiwindow window manager and
> X11 Window Properties as well as the questions you brought up.
> 
> The first question :
> 
>> it should check the message type as well, as e.g.
>> a different type mesage could cause WM_WM_CHANGE_STYLE to be ignored.
> 
> Not sure what the "type" of a message means.
> Do you mean window manager message WM_xxxxx that is processed by
> winMultiWindowWMProc() where it is alreadychecked in HaveMessage(),
> or do you mean X message XCB_xxxxxx that is processed by
> winMultiWindowXMsgProc()?
> Maybe you can provide an example of another message type?

I mean the various WM_WM_* messages, e.g. WM_WM_NAME_EVENT.

> 
> The second question:
> 
>> Successive WM_WM_CHANGE_STATE messages cancel out each other
>> isn't always true ex. _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT
>> followed by _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ.
> 
> Inspecting the code that deal with XCB_CLIENT_MESSAGE, it seems already
> true before the patch: The window goes maximized only if X client do one
> _WM_STATE_ADD action with _NET_WM_STATE_MAXIMIZED_VERT and
> _NET_WM_STATE_MAXIMIZED_HORZ simultaneously specified. Otherwise,
> the WM_WM_CHANGE would not be sent to the queue.

Well, that's arguably a bug in this code :)

> Further, in UpdateWindowState(), the state and related X properties are
> either all-overwritten or all-skipped.
> There seems to be no state property half-update case if we skip
> UpdateWindowState().
> 
> In anyway, I just came out somewhat different patch attached.
> Where it just skips the Win32 ShowWindow() call instead of
> skipping processing WM_WM_CHANGE_STATE. It might be better because
> the X properties are still always updated in each in WM_WM_CHANGE_STATE.
> Maybe you could provide further comment.

I applied a different fix in xserver 21.1.4-1, which prevents the 
redundant messages which winAdjustXWindowState() was queuing, which 
caused this thrashing to occur.

This makes your test case work correctly, but perhaps you could verify 
that the problem is also fixed with the application you use.