Opened 3 weeks ago

Closed 3 weeks ago

#1170 closed Feature Request (fixed)

x11_in_gtk: take into account some scenarios in x_window_is_valid

Reported by: jpcima Owned by: dave
Priority: minor Component: Suil
Keywords: Cc:

Description

I develop a lv2 project where I experiment various kinds of UI.
The current toolkit of my experiments is Tk, in perspective of studying the feasibility of directly embedding puredata GUIs into plugins.

Embedding Tk works in all supported toolkits, but I have discovered an anomaly in GTK: CPU usage goes up to 70-80% under GTK2. GTK3 has an internal temporization making it less noticeable, but the symptom is still present.

I observed the culprit was the x_window_is_valid test in suil, which returned false all the time. It resulted in queuing resize events constantly and this was the source of the problem.

I have noticed that x_window_is_valid detects the validity of a window by telling whether it is in the list of the host window's children. However in my case, the child window is not a direct child but in fact 2 levels down.

I propose a fix to this problem by checking instead if the window is a descendant, instead of a child, in breadth first search order. See attached patch.


The window hierarchy, as reported by xwininfo -tree, is like this.

  Root window id: 0x126 (the root window) (has no name)
  Parent window id: 0x417271 (has no name)
     2 children:
     0x3e00023 (has no name): ()  600x400+0+19  +41+114
        1 child:
        0x3e00003 "jalv.gtk": ("jalv.gtk" "Jalv.gtk")  600x400+0+0  +41+114
           1 child:
           0x420000e "lv2-skeleton": ("lv2-skeleton" "Lv2-skeleton")  600x400+0+0  +41+114
              1 child:
              0x4200003 (has no name): ()  600x400+0+0  +41+114
                 1 child:
                 0x420000f (has no name): ()  105x28+247+0  +288+114
     0x3e00021 (has no name): ()  1x1+-1+-1  +40+94

0x3e00003 is the parent window given by lv2, and 0x4200003 is the widget returned by the plugin. The hierarchy has an intermediate window in between.

I cannot figure out how this intermediate has appeared. I have printed every XCreateWindow and XCreateSimpleWindow in Tk and Gdk, and this mystery window was not created by either toolkit. I ignore what to assume except some obscure Xserver magic but this leaves me somewhat clueless to be honest.

As such, the proposed fix is certainly discutable. Some input would be definitely appreciated on the issue. Thanks

Attachments (1)

descendants.diff (3.9 KB) - added by jpcima 3 weeks ago.

Download all attachments as: .zip

Change History (3)

Changed 3 weeks ago by jpcima

comment:1 Changed 3 weeks ago by jpcima

Ok forget it I'm being utterly stupid here.
I missed one window creation in Tk, and the window I look for is actually created lazily, during the first few events of the queue. By pumping the event queue during init time, the windows creates itself, only leaving me to find how to retrieve its ID.
Will close the bug as soon as I confirm that everything works.

comment:2 Changed 3 weeks ago by jpcima

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.