Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342755

Summary:

Grab lost when setRedraw called in GTK 2.18 and greater

Product:

[Eclipse Project] Platform

Reporter:

Bogdan Gheorghe <gheorghe>

Component:

SWT

Assignee:

Silenio Quarti <Silenio_Quarti>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

h1055071, pwebster, Silenio_Quarti

Version:

3.7

Target Milestone:

3.7 M7

Hardware:

OS:

Linux

Whiteboard:

Bug Depends on:

Bug Blocks:

321560

Attachments:

Description	Flags
Test patch	none

Description Bogdan Gheorghe

2011-04-13 15:23:52 EDT

If setRedraw is called while grabbing a control, the grab is lost and all subsequent mouse events are not delivered to the grabbed control. This was introduced as part of the fix for Bug 290395.

Here is a snippet: 

import org.eclipse.swt.SWT;
import org.eclipse.swt.events.MouseAdapter;
import org.eclipse.swt.events.MouseEvent;
import org.eclipse.swt.events.PaintEvent;
import org.eclipse.swt.events.PaintListener;
import org.eclipse.swt.widgets.Canvas;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.widgets.Listener;
import org.eclipse.swt.widgets.Shell;


public class RedrawSnippet {
public static void main(String[] args) {
	Display display = new Display();
	final Shell shell = new Shell(display);

	final Canvas c = new Canvas(shell, SWT.NONE);
	c.setBackground(display.getSystemColor(SWT.COLOR_BLUE));
	final Canvas c2 = new Canvas(shell, SWT.NONE);
	c2.setBackground(display.getSystemColor(SWT.COLOR_RED));
	
	c.addMouseListener(new MouseAdapter() {
		public void mouseUp(MouseEvent e) {
			System.out.println("Mouse up");
		}
		public void mouseDown(MouseEvent e) {
			c.setRedraw(false);
			c.setRedraw(true);
			
		}
	});
	
	shell.addListener(SWT.Resize, new Listener() {
		
		public void handleEvent(Event event) {
			c.setBounds(shell.getClientArea());
			c2.setBounds(shell.getClientArea());
		}
	});
	shell.pack();
	shell.open();
	while (!shell.isDisposed()) {
		if (!display.readAndDispatch())
			display.sleep();
	}
	display.dispose();
}
}

Comment 1 Bogdan Gheorghe

2011-04-13 15:51:51 EDT

The original bug fix for Bug 290395 was hiding and showing the window and this caused the grab to be lost.

The reason we needed to hide/show the window is that GTK is not sending out a visiblity notify event when the window becomes unobscured. We depend on that event to optimize the drawing of completely obscured widgets (GTK still sends the paint events for obscured widgets). 

This patch turns off this optimization for GTK > 2.17.11. Note that this is not a good final solution as it will introduce considerable performance degradation for Eclipse given that there are many obscured editors and perspectives.

On a side note, we believe that this will fix Bug 333965. Paul, could you give this a spin on your home machine?

Comment 2 Bogdan Gheorghe

2011-04-13 15:52:23 EDT

Created attachment 193191 [details]
Test patch

Comment 3

2011-04-20 05:35:00 EDT

Hi, did this fix the issue?

Comment 4 Silenio Quarti

2011-04-21 17:21:49 EDT

Fixed > 20110421

Comment 5

2011-04-21 17:24:23 EDT

(In reply to comment #4)
> Fixed > 20110421

Thank-you! I shall test it when the I build is available.

Comment 6 Paul Webster

2011-04-25 16:08:27 EDT

Did this make it into the weekend I builds?  I still have Bug 333965 in org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3730

PW

Comment 7 Bogdan Gheorghe

2011-04-25 17:32:05 EDT

The changes released last week were just addressing the GEF bug. We weren't sure at the time that the attached patch was correct. We have since confirmed that the patch is right and have released it to HEAD. It will be available for testing in tomorrow's I-build.

Comment 8

2011-04-26 13:17:24 EDT

I tested this on build eclipse-SDK-I20110425-1800-linux-gtk.

In GEF Editors it is now possible to drag the palette splitter as detailed in Bug 321560. The only downside is that there are repaint issues as mentioned above. Dragging the palette splitter from left to right leaves a trail of slow repainted image sections.

The "monkey patch" submitted in a comment to Bug 321560 actually works better.