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

Bug 510946

Summary:	FXCanvasEx causes serious rendering delays when its bounds are too big.
Product:	[Tools] GEF	Reporter:	Matthias Wienand <matthias.wienand>
Component:	GEF FX	Assignee:	gef-inbox <gef-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	1.1.0
Target Milestone:	5.0.0 (Oxygen) M5
Hardware:	All
OS:	All
Whiteboard:

Description Matthias Wienand

2017-01-24 07:43:03 EST

Currently, some inconveniences w.r.t. the JavaFX/SWT integration are solved by subclassing FXCanvas and adding the missing functionality (FXCanvasEx). However, when using FXCanvasEx, the performance decreases dramatically if the bounds of the canvas are too big.

Comment 1 Matthias Wienand

2017-01-24 11:18:10 EST

I found that the SWT update() call that is performed from within the RedrawingEventDispatcher decreases the performance significantly. The redraw() call is necessary for the FXCanvasEx to stay responsive even if a large number of events has to be processed. However, the update() call is detrimental as it forces the event dispatcher to wait for the canvas to redraw. Hence, I removed the update() call and tested interactions with a large viewport (and a large number of visuals) on linux and mac os. The code is published on the master branch, therefore, I resolve this ticket as fixed for 5.0.0 M5.

Comment 2 Matthias Wienand

2017-01-24 11:21:33 EST

A potential workaround (for GEF4 1.x) is documented in the GEF forum at: https://www.eclipse.org/forums/index.php?t=msg&th=1083918&goto=1752518&#msg_1752518