swt-designer really really slow... is this normal???

[cmdrfunk]

Any time I make any changes in the visual editor the designer can take anywhere from 10 seconds to FIVE MINUTES to apply the changes. This even occurs JUST when i make a new application with nothing in it but maybe one button. The waiting for the action to take place takes complete control of X, and I can't do anything with my computer but wait. A little window in the upper left hand corner flashes a bit too, but it's not really visible.

All I do is: New swt-designer project... new swt-designer application... set grid manager(which seems really sluggish)... then i can try to add a button or whatever and it takes sometimes a few minutes to add anything. The rest of eclipse (and other applications) runs just fine.

I've tried it with Eclipse 2.1, 3.0M4, and 3.0M5 with the same results... I forget which version of SWT-Designer I used for 2.1, but with 3.0M4 and 3.0M5 I used 1.2.1 and 1.2.2b, respectively.

Computer specs:
Fedora Linux (newly installed)
Athlon 2100+ w/ 512 megs ram, Radeon 9500
Running KDE

Anyone else with similar experiences? I've googled a bit but no one seems to complain about any speed issues. I don't mind a little lag, but waiting MINUTES for a change is ridiculous. Any suggestions?

Thanks,

Jared

[Eric Clayberg]

Any time I make any changes in the visual editor the designer can take anywhere from 10 seconds to FIVE MINUTES to apply the changes.

The only thing I can think of that might slow it down would be that it is encountering a long series of exceptions that are being written to the log file. Check the Eclipse ".log" file for any exceptions and send them to support@swt-designer.com. Also, are you using Eclipse/Linux/GTK or Eclise/Linux/Motif? We support the GTK version, but there are still some problems with the Motif version. We have only tested under SuSE and RedHat (which are the same platforms that eclipse.org tests Eclipse on), so I don't know whether this would have anything to do with your specific Eclipse distribution (I have never heard of Fedora Linux before).



Computer specs:
Fedora Linux (newly installed)
Athlon 2100+ w/ 512 megs ram, Radeon 9500
Running KDE

[cmdrfunk]

Fedora is the new version of Redhat. Redhat is no longer supporting the "little people." They're only offering the Enterprise edition now. The Fedora Project is taking over the consumer-level part of the redhat distribution. It's still supported by redhat, just not officially. In effect, it's redhat 10 with a new name.

I'm using Eclipse/Linux/GTK.

The .log file doesn't have any exceptions in it. I even deleted it and ran Eclipse and the plugin again for a few minutes, adding 3 buttons, which took me about 7 minutes to do on a blank form. Wow that's slow No entries were added to .log. It's really too bad, it seems like a decent designer otherwise.

Thanks,

Jared

[Eric Clayberg]

The Fedora Project is taking over the consumer-level part of the redhat distribution. It's still supported by redhat, just not officially. In effect, it's redhat 10 with a new name.

Wow...and I just updated to RedHat 9.

The .log file doesn't have any exceptions in it. I even deleted it and ran Eclipse and the plugin again for a few minutes, adding 3 buttons, which took me about 7 minutes to do on a blank form. Wow that's slow

Yes. That is unnaturally slow. Under RedHat 9, I can add three buttons in about three seconds. Can you try it with Eclipse 3.0 M5 and the new SWT Designer 1.2.2 beta update that we released last night? It includes a diagnostic mode (on the pref page) that might capture more information to the log about what is happening.

[cmdrfunk]

It is going faster now, thanks.

But it still takes a bit to add/change things. Changing the name of, for example, a text box is taking about 15 seconds. Most other events are happening more quickly, though no where near adding a button per second like you say... more along the lines of 4-5 seconds.

It's good enough to work with, though.

Thanks,

Jared Felton

[cmdrfunk]

Ok, i take that back.

Adding items to a ToolBar is taking minutes again, making X unresponsive to mouse presses or key presses until it's done.

I turned on that diagnostic mode you mentioned, and nothing is being added to the .log

Why exactly does that window flash in the upper left corner repeatedly as an example of the window you're creating? In the periods that it's locking forever, that window is just a gray square on the screen. I don't see anything like that happening the demos. Can you turn that off? Maybe that's why it's going so slow.

[Eric Clayberg]

Adding items to a ToolBar is taking minutes again, making X unresponsive to mouse presses or key presses until it's done.

Does it get slower over time? Do you have any other plugins loaded? How do you have your Eclipse memory settings configured. By default, Eclipse is configured to use very little memory (it maxes out at 64MB). If you haven't changed the default settings, you are probably running into massive swapping and/or garbage collection. Try setting the initial and maximum memory usage for Eclipse using the following command line arguments...

-vmargs -Xms128M -Xmx256M

Here is some info on improving Eclipse memory usage that might help...

http://www.instantiations.com/swt-designer/docs/install.html

[javaDev]

I am having the same problem with my application environment as well. I am running on WinXP Pro, 2Ghz, 1G ram, WSAD 5.1.1, SWT Designer Pro ver 1.2.3 for Eclipse2.1.

The cause of the problem appears to be related to instances when I have switched from the visual designer to the source and made manual code updates. Initially, there was no problem with this but now I am encountering situations where, if I am in the visual designer, no matter what change I make however minor causes the class to perform a lengthly regeneration of source. It is manifested as a flashng program icon in the Windows taskbar with the name of the shell. This can take 10 seconds to a few minutes, and often will not complete correctly at all. In WSAD 5.0 the entire IDE would exit with a JVM termination code 128. In WSAD 5.1.1, I will get a stack trace error and a recommendation that I close WSAD. This is happening OFTEN.

I have tried bumping up the JVM memory to 64, 128, and 256. However, from observing the task manager, it is CPU not memory that redlines.
I have been trying to modify the IDE preferences to control the frequency of regeneration. When I am working in the source and save a change, I do not get this error.

I would appreciate any thoughts, recommendations, or solutions anyone may have on this issue. I will continue to research it and will post an answer if I find one.

[Eric Clayberg]

The cause of the problem appears to be related to instances when I have switched from the visual designer to the source and made manual code updates. Initially, there was no problem with this but now I am encountering situations where, if I am in the visual designer, no matter what change I make however minor causes the class to perform a lengthly regeneration of source. It is manifested as a flashng program icon in the Windows taskbar with the name of the shell. This can take 10 seconds to a few minutes, and often will not complete correctly at all. In WSAD 5.0 the entire IDE would exit with a JVM termination code 128. In WSAD 5.1.1, I will get a stack trace error and a recommendation that I close WSAD. This is happening OFTEN.

Does this happen with every window you edit or specific ones? This sounds like you are encountering some repeated exception (which might be the result of a parsing problem). If a large number of exceptions are being written to the WSAD ".log" file, it will have a definite side of effect of causing the IDE to slow to a crawl. When this occurs, you need to either post the relevant (e.g., SWT Designer related) log entries here or just send the entire log file to support@swt-designer.com.

You might also consider giving SWT Designer v1.2.4 a try. Whatever exception you might be encountering might have already been fixed.

I have tried bumping up the JVM memory to 64, 128, and 256. However, from observing the task manager, it is CPU not memory that redlines.

What are your exact WSAD startup parameters?

I have been trying to modify the IDE preferences to control the frequency of regeneration.

What preferences are those?

[javaDev]

Here is a snippet of the log file:
!MESSAGE Designer internal error: null
!STACK 0
java.lang.StackOverflowError
at java.lang.Throwable.<init>(Throwable.java)
at java.lang.Throwable.<init>(Throwable.java)
at java.lang.StackOverflowError.<init>(StackOverflowError.java:51)
at org.eclipse.swt.widgets.Control.windowProc(Control.java)
at org.eclipse.swt.widgets.Display.windowProc(Display.java)
at org.eclipse.swt.internal.win32.OS.SendMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.SendMessage(OS.java)
at org.eclipse.swt.widgets.Group.getClientArea(Group.java)
at com.swtdesigner.model.swt.layout.GridLayoutCopy.layout(SourceFile)
at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java)
at org.eclipse.swt.widgets.Group.WM_SIZE(Group.java)
at org.eclipse.swt.widgets.Control.windowProc(Control.java)
at org.eclipse.swt.widgets.Display.windowProc(Display.java)
at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java)
at org.eclipse.swt.widgets.Group.callWindowProc(Group.java)
at org.eclipse.swt.widgets.Control.windowProc(Control.java)
at org.eclipse.swt.widgets.Display.windowProc(Display.java)
at org.eclipse.swt.internal.win32.OS.EndDeferWindowPos(Native Method)
at org.eclipse.swt.widgets.Composite.resizeChildren(Composite.java)
at org.eclipse.swt.widgets.Composite.resizeChildren(Composite.java)
at org.eclipse.swt.widgets.Composite.setResizeChildren(Composite.java)
at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java)
at org.eclipse.swt.widgets.Control.windowProc(Control.java)
at org.eclipse.swt.widgets.Display.windowProc(Display.java)
at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java)
at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java)
at org.eclipse.swt.widgets.Control.windowProc(Control.java)
at org.eclipse.swt.widgets.Display.windowProc(Display.java)
at org.eclipse.swt.internal.win32.OS.SetWindowPos(Native Method)
at org.eclipse.swt.widgets.Control.setBounds(Control.java)
at org.eclipse.swt.widgets.Control.setBounds(Control.java)
at com.swtdesigner.model.swt.layout.GridLayoutCopy.layout(SourceFile)
at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java)
at org.eclipse.swt.widgets.Group.WM_SIZE(Group.java)

Here is another section of the log that repeats many times:
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java)
at com.swtdesigner.model.JavaInfo.firePropertyChange(SourceFile)
at com.swtdesigner.model.JavaInfo.notifyPropertyChanged(SourceFile)
at com.swtdesigner.model.JavaInfo.notifyPropertyChanged(SourceFile)
at com.swtdesigner.model.swt.widgets.control.ControlInfo.getShotBounds(SourceFile)
at com.swtdesigner.gef.edit.swt.control.ControlEditPart.refreshVisuals(SourceFile)
at org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractEditPart.java)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh(AbstractGraphicalEditPart.java)
at com.swtdesigner.gef.edit.swt.composite.CompositeEditPart.refresh(SourceFile)
at com.swtdesigner.gef.edit.common.JavaEditPart.refreshVisualsTree(SourceFile)
at com.swtdesigner.gef.edit.common.JavaEditPart.refreshVisualsTree(SourceFile)
at com.swtdesigner.gef.edit.common.JavaEditPart.refreshVisualsTree(SourceFile)
at com.swtdesigner.gef.edit.common.JavaEditPart.refreshVisualsTree(SourceFile)
at com.swtdesigner.gef.edit.common.JavaEditPart.refreshVisualsTreeFromRoot(SourceFile)
at com.swtdesigner.gef.edit.common.JavaEditPart.propertyChange(SourceFile)

Here are the startup paramters on the target area of my WSAD icon:
"D:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.1\wsappdev.exe" -vmargs -Xms128M -Xmx512M


The setting in WSAD that I have tried to adjust so far are in:
Window -> Preferences -> Java -> Update Java Views -> On save only

However, this setting has no effect on the SWT designer. The errors occur within the visual developer when modifying or adding any item on the window.

Thus far, my solution to the problem has been to back-off any changes I have made past the point that the errors begin, examine the source again and determine if the code has been altered into an erroneous state and try to correct the problems, and to try to proceed again slowly adding my changes.

[Eric Clayberg]

We have never encountered this problem before.

Does this happen with every window you edit or specific ones?

Can you send us the window where this problem occurs?

Have you had a chance to try v1.2.4?

[javaDev]

I have send source code and the log file to your support email.

The error is happening in the visual designer when I try to interact with anything - buttons, text, groups, composites, etc.

I have not had a chance to work with ver. 1.2.4 yet. I will see if I can obtain it.

Thanks

[Eric Clayberg]

The error is happening in the visual designer when I try to interact with anything - buttons, text, groups, composites, etc.

Does it happen with any window you edit or just the one you sent us?

[javaDev]

Only that window so far.

[Eric Clayberg]

Only that window so far.

As I suspected. This seems to be caused by a problem with our StackLayout code when handling deeply nested containers. We have a tentative fix that we are currently testing and should be able to send to you soon.