Community
Participate
Working Groups
Steps: - Create a Flow example - Create a few shapes Result: - Notice that the shapes snap to new position and don't animate. Alternate: - Open close palette drawer and notice that the drawer doesn't animate like on other platforms. Note: - Flow example should migrate to new LayoutAnimator utility to be consistent.
Animations also fail on GTK with the compiz extension enabled. The Compiz extension is the one that gives all the new eye candy (like transparent windows), and it is becoming more common on many linux systems (like Ubuntu).
I have looked into this problem a bit more and discovered a few things. The animator works by spinning in the UI thread, making slight adjustments to the position of the figures, and then calling redraw / update. I wrote a small SWT snippet that does this (For 2 seconds it changes the size of a circle, and causes redraw / update). Under windows and linux this works fine, however, when I enable the compiz extension on Linux it fails (to animate). This is very similar to how the animator works. Now, if I sleep the UI thread after each redraw, it animates. So one of two things is happening: 1) We need to sleep the UI thread (for some reason?) 2) We are overloading the queue with too many redraw / updates. Now we can fix this by sleeping our animator (we can sleep such that we achieve 30fps), or we can talk to the SWT crew and see if we really should be hammering the canvas with redraw / updates.
I was able to get my hands on a MAC and I tried this out there. On a mac it seems like you *can't* call successive refresh / updates without calling readAndDispatch() on the display in between. So to summarize: 1) Windows and GTK+ you can pound the system with refresh / updates 2) GTK+ with Compiz you can't pound the system this way (X Windows seems to need some time to work before you call more refresh / updates, sleeping fixes this) 3) Mac you *must* call readAndDispatch() between successive calls of refresh / update. I'm not sure if this is considered an SWT bug since I have a small snippet that runs differently on each platform, or if the snippet is not considered correct (since the snippet simply hogs the UI thread and constantly redraws a shape on a canvas). Randy, you have more experience with SWT than me, do you have any thoughts?
At least in the mac case, I believe this is fundamentally an SWT bug, which has just been fixed: bug 193362
I use animation in GEF as a feature in our RCP application (http://www.archi.cetis.ac.uk). It works for Windows and Mac Carbon 32-bit version but NOT for Mac Cocoa 32-bit. Is this fixable? Are there any pointers to where the problem is so I might perhaps see if I can come up with a patch. Or is the problem more fundamental than that? Should I open a new bug report?
Tested OK on Ubuntu Linux 32-bit. (Note, a wrong URL in last comment, should be http://archi.cetis.ac.uk/)
I just tested again on Eclipse Version: 3.6.1 Build id: M20100909-0800 with GEF 3.6.1.v20100908-1100 on Mac OS X 10.6.6 and it now works! Something changed maybe in Eclipse 3.6.1? Seems to be fixed now! :-)
(In reply to comment #7) > I just tested again on Eclipse Version: 3.6.1 Build id: M20100909-0800 with GEF > 3.6.1.v20100908-1100 on Mac OS X 10.6.6 and it now works! Something changed > maybe in Eclipse 3.6.1? > > Seems to be fixed now! :-) Well, that's great. I love bugs that resolve themselves... Ian, could you check how the GTK/Compiz setting is affected?
Sorry, it isn't working. I've just double-checked things. It's still broken under one set of circumstances. We animate a setBounds Command on GEF Figures so that when the user does an Undo or a Redo the figure returns to its original size/position with an animation effect. For this we use IFigure.addLayoutListener(LayoutAnimator.getDefault()); for the main diagram figure and for any child figures. Then in an Undo/Redo method of a Command we can call Animation.markBegin() then do the setbounds operation and then call Animation.run(animationSpeed). On Mac Cocoa the animation only occurs if Undo/Redo is performed from the menu or toolbar items. If however I use the key shortcuts (Cmd-Z and Cmd-Shift-Z) then we do not get the animation.
(In reply to comment #9) > On Mac Cocoa the animation only occurs if Undo/Redo is performed from the menu > or toolbar items. If however I use the key shortcuts (Cmd-Z and Cmd-Shift-Z) > then we do not get the animation. Well, that sounds like it could be another issue. Could you try to debug into it and locate what makes up the difference?
Created attachment 187955 [details] Test case that shows the problem I made a test case attached. It's the "Shapes" GEF example. I tagged the modifications to add animation with the comment // *** PB added code *** Modified ShapeEditPart added line 128: f.addLayoutListener(LayoutAnimator.getDefault()); Modified DiagramEditPart added line 91: f.addLayoutListener(LayoutAnimator.getDefault()); Modified ShapeSetConstraintCommand to change the execute(), redo() and undo() methods to add the animation. To reproduce: 1. Run the attached Shapes example in a workbench instance so you can create a new Shapes file. 2. Add a shape to the canvas. 3. Move the shape to a new position on the canvas. 4. Now do an "Undo" from the menu. You should see the shape slide back to its original position. 5. Now do a "Redo" from the menu. You should see the shape slide back to its new position. BUT if you do the same Undo/Redo with the key shortcuts (Cmd-Z / Cmd-Shift-Z) you will not see the animation. You will see instead a pause (the animation duration of 500 ms).
(In reply to comment #11) Phil, could you rather apply a patch (right-click on Project, Team -> Create patch...)? That would make it easier to consume.
Created attachment 187959 [details] Patch for modified Shapes example Patch for modified Shapes example.
(In reply to comment #13) > Created attachment 187959 [details] > Patch for modified Shapes example > > Patch for modified Shapes example. Thanks!
Created attachment 188009 [details] Patch for LayoutAnimator, demonstrating that Display#readAndDispatch() is still required on the Mac In correspondence to what Ian has already investigated, I can confirm that a call to Display#readAndDispatch() is still required on Mac Cocoa (using Eclipse 3.7) for the animation to work. I attached a patch (for LayoutAnimator) that demonstrates this with Phil's modified version of the shapes example (subsumed by attachment #187959 [details]). I think we should raise an issue for the SWT team, because this is inconsistent cross-platform behavior. Ian, do you still have your SWT-standalone snippet at hand?
(In reply to comment #4) > At least in the mac case, I believe this is fundamentally an SWT bug, which has > just been fixed: bug 193362 Interestingly, the snippet attached to bug #193362 works on Mac Cocoa (using Eclipse 3.7) without a need for Display#readAndDispatch(). As such, our problem here seems to be a little bit different...
Excuse my slowness in understanding this but the animation *does* work on Cocoa if the event comes from choosing the Undo or Redo menu item, but *doesn't* work from a key press. Is it because the key press is on a different thread than the menu item one?
(In reply to comment #17) > Excuse my slowness in understanding this but the animation *does* work on Cocoa > if the event comes from choosing the Undo or Redo menu item, but *doesn't* work > from a key press. Is it because the key press is on a different thread than the > menu item one? Well, both are initiated from within Display#readAndDispatch(). But in case of the undo menu, the animation is executed in the context of Display#runDeferredEvents(), while in case of the key stroke, it is executed in the context of Display#sendEvent(). I have modified the SWT snippet of bug #193362 to issue the repaint() not by means of a button (where the issue was fixed), but as the result of a keypress instead. This way the issue is reproducable using SWT alone: package swt.bugs; import org.eclipse.swt.SWT; import org.eclipse.swt.events.KeyEvent; import org.eclipse.swt.events.KeyListener; import org.eclipse.swt.events.PaintEvent; import org.eclipse.swt.events.PaintListener; import org.eclipse.swt.graphics.Rectangle; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Canvas; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class AnimationTest { /** * @param args */ public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); final Rectangle r = new Rectangle(0, 0, 100, 20); final Canvas c = new Canvas(shell, SWT.DOUBLE_BUFFERED); c.addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { e.gc.setBackground(display.getSystemColor(SWT.COLOR_BLUE)); e.gc.fillRectangle(r); } }); shell.addKeyListener(new KeyListener() { public void keyReleased(KeyEvent e) { // TODO Auto-generated method stub } public void keyPressed(KeyEvent e) { for (int i = 0; i < 100; i++) { r.y += 1; c.redraw(); c.getDisplay().update(); c.getDisplay().readAndDispatch(); // needed on mac } } }); shell.setSize(200, 200); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Reopened SWT bug #193362, added a dependency to keep track of the progress there.
Filed new bug #337025 to keep track of the GTK/Compiz issue, as the problem reported here seems to be independent of the GTK/Compiz problem. Changed summary to indicate that this bug is used to keep track of the Mac OS X related problem only.
I will take care of verifying that with Eclipse > 20110211 the problem is fixed on Carbon as well as Cocoa.
Tested my use case on Eclipse N20110211-2000 and GEF I201101272050 on both Cocoa and Carbon and the result is........It Works! The figures animate as expected when initiated from key presses and from menu actions.
Verified that also the snippet now works as expected on Mac Cocoa and Carbon with Eclipse 3.7 N20110213. Resolving as FIXED in 3.7M6 though.
(In reply to comment #23) > Verified that also the snippet now works as expected on Mac Cocoa and Carbon > with Eclipse 3.7 N20110213. Resolving as FIXED in 3.7M6 though. Well done. Thanks!
