[10] Review request for 8176844: Menus not always selected properly with GTK 3

[Semyon Sadetsky]

Okay. Thank you to you all!

The root cause why we need to add sync is a new way to grab/ungrab focus 
used in the GTK3 glass implementation.

The GTK2 way to grab/ungrab is still applicable in GTK3 though it is 
deprecated. But the used GTK3 grab/ungrab is deprecated as well since 
version 3.20 (Ubuntu 16.04 LTS has 3.18 assigned, but newer OS versions 
will come with higher number).

David, do you think we could use the same GTK2 grab/ungrab for GTK3 to 
avoid sync?

Also, I found some other potential issues in the GTK3 implementation.

1. gdk_device_manager_get_client_pointer() is used for getting pointer 
position and for D&D pointer grab, and the documentation to this 
function says:

You should use this function seldomly, only in code that isn’t triggered 
by aGdkEvent 
<https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html#GdkEvent>and 
there aren’t other means to get a meaningfulGdkDevice 
<https://developer.gnome.org/gdk3/stable/GdkDevice.html>to operate on.

but we are using it in processing of GDK_BUTTON_PRESS, 
GDK_BUTTON_RELEASE and GDK_DRAG_STATUS events.

2. GList obtained by gdk_device_manager_list_devices() during 
grab/ungrab operations is not freed,  so it causes memory leak.

I will file bug for 1. and for 2. if the new GDK3 grab/ungrab will be 
preserved.

--Semyon


On 04/04/2017 04:53 PM, Kevin Rushforth wrote:
> I raised the same concern in the JBS issue, especially for mouse and 
> keyboard events.
>
> -- Kevin
>
>
> Jim Graham wrote:
>> I don't think I was specifically involved in AWT fixes for that 
>> issue, but the concerns that David raises are all valid and Phil 
>> correctly points out that this is much worse in a network display 
>> environment...
>>
>>             ...jim
>>
>> On 4/4/17 3:53 PM, Philip Race wrote:
>>> AWT used to have really bad at X11 remote display and
>>> it was looked at a few times and I think it was improved
>>> noticeably when we could get rid of  "round trip" requests.
>>> I think Jim had a hand in some of that work.
>>>
>>> So I am sure a round trip - or similar - is bad for performance.
>>>
>>> If you want to measure the effect of such change, remote display to
>>> your desktop from a machine in a geographically distant site.
>>>
>>> It is the latency that kills performance, not the bandwidth.
>>>
>>> -phil.
>>>
>>> On 4/4/17, 3:43 PM, David Hill wrote:
>>>> On 4/4/17, 1:27 PM, Semyon Sadetsky wrote:
>>>>> Hello Kevin & David,
>>>>>
>>>>> Please review the fix for jfx9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176844
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/
>>>>>
>>>>> --Semyon
>>>>>
>>>>
>>>> Semyon,
>>>>
>>>> I have been sitting here for a while thinking about adding
>>>> gdk_display_sync(gdk_display_get_default());
>>>>
>>>> I can see why this might address many issues, as it flushes the 
>>>> pipeline and waits for the X11 server to catch up.
>>>> That is balanced out by a historical distrust of using XSync in any 
>>>> situation where the consequences.
>>>>
>>>> Part of me thinks it is minimal overhead though, the other part 
>>>> does not like stalling the asynchronous X11 design.
>>>>
>>>> The other part of me would like to use this only for the window 
>>>> events that need it, instead of all of them.
>>>>
>>>> and I found this in hte GTK docs:
>>>> gdk_events_pending ()
>>>> Waits for a GraphicsExpose or NoExpose event from the X server. 
>>>> This is used in the GtkText and GtkCList widgets in
>>>> GTK+ to make sure any GraphicsExpose events are handled before the 
>>>> widget is scrolled.
>>>>
>>>> so perhaps this should be used in some cases (like setVisible).
>>>>
>>>> sigh.
>>>>
>>>> Will try to make up my mind tomorrow.
>>>>
>>>> Dave.
>>>>