Bug 546248 - [GTK3] Composite receives to much repaint events
Summary: [GTK3] Composite receives to much repaint events
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.12   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.13 M3   Edit
Assignee: Eric Williams CLA
QA Contact:
URL:
Whiteboard: RHT
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-04-09 10:31 EDT by Thomas Singer CLA
Modified: 2019-08-20 10:14 EDT (History)
3 users (show)

See Also:

Attachments
Sample code to reproduce (1.42 KB, text/plain)
2019-04-09 10:32 EDT, Thomas Singer CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Singer CLA 2019-04-09 10:31:08 EDT 
Please launch the attached snippet. 1 or 2 Paint events occur. If you move the mouse over the window, it will show some MouseMove events followed by Paint events. But

a) a lot of Paint events occur between having moved the mouse and the MouseHover event occurs, and

b) up to 3s after the MouseHover event occurred, a lot of Paint events are received.

4:29:52 PM: p
4:29:53 PM: mpmpmpmpmpmpmppp
4:29:53 PM: ppppppppppppppp
4:29:53 PM: ppppppphpppppppp
4:29:54 PM: ppppppppppppppp
4:29:54 PM: ppppppp
4:29:55 PM: ppppppppp
4:29:55 PM: ppppppppppppppp
4:29:55 PM: ppppppppppppppp
4:29:56 PM: ppppppppppppppp
4:29:56 PM: pppppp
Comment 1 Thomas Singer CLA 2019-04-09 10:32:20 EDT 
Created attachment 278188 [details]
Sample code to reproduce
Comment 2 Thomas Singer CLA 2019-04-09 10:49:41 EDT 
On macOS and Windows we do not receive any Paint event when moving the mouse.

macOS:
4:48:16 PM: ppp
4:48:18 PM: mmmmmmmmmmmmm
4:48:18 PM: mmmmmmmmmmmmmmmmmmmm
4:48:18 PM: mmmmmmmmmmmmmmmmmmmmmmmmmmmm
4:48:19 PM: m
4:48:19 PM: h
4:48:21 PM: mmmmmmmmm
4:48:21 PM: mmmmmmmmmmmmmmmmmmmmmmmmmmm
4:48:21 PM: mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
4:48:21 PM: mmmmmmmmmmmmmmmm
Comment 3 Eric Williams CLA 2019-04-09 11:01:19 EDT 
Do you experience some bug because of this? Based on the way GTK does drawing this looks normal to me.
Comment 4 Thomas Singer CLA 2019-04-09 14:27:48 EDT 
This seems to cause some performance problems for non-trivial ownerdrawn controls.
Comment 5 Eric Williams CLA 2019-04-10 09:44:13 EDT 
(In reply to Thomas Singer from comment #4)
> This seems to cause some performance problems for non-trivial ownerdrawn
> controls.

Is this a regression in SWT or a general observation with GTK3?
Comment 6 Thomas Singer CLA 2019-04-10 10:48:09 EDT 
This is a general observation about GTK3. I haven't compared to previous GTK/SWT versions.

If, for example, an expensive repaint needs 50ms, the additional repaint events sum up to waste ~1s without any benefit. I would have expected at least the double-buffered control to ignore such unnecessary repaints.
Comment 7 Eric Williams CLA 2019-08-13 17:10:19 EDT 
The paint events were introduced in this commit:

https://gitlab.gnome.org/GNOME/gtk/commit/8b85db08e55e4a34829129f74946497bc769d647

between GTK3.14 and 3.16. I'll keep investigating as to the cause.
Comment 8 Thomas Singer CLA 2019-08-14 01:38:34 EDT 
Thanks, this is much appreciated.
Comment 10 Eric Williams CLA 2019-08-16 09:24:46 EDT 
(In reply to Eclipse Genie from comment #9)
> Gerrit change https://git.eclipse.org/r/147730 was merged to [master].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/
> ?id=7081cee06fc084501628dbf6ad48c5e95771a06d

In master now. Should reduce the overhead of paint events in the general IDE by quite a bit.
Comment 11 Eric Williams CLA 2019-08-20 10:14:11 EDT 
Verified in I20190820-0600.