This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Try to press Print Screen on windows (a screenshot of will be taken and placed into the clipboard). Navigating in a TTV after that will be extremely slow.
Created attachment 12720 [details] Part of a threads dump
The problem is triggered by org.openide.explorer.ExplorerActionsImpl.updatePasteAction trying to update the Paste toolbar/menu action's enabled state. The real problem is in: org.netbeans.core.NbClipboard.getContents nothing to do with the ttv per se. I've seen similar problems in other cases where a large image was on the clipboard and things slowed to a crawl, and the same stack trace showed when I dumped the stack. Suggestion for how to fix this: - Track application activation (probably KeyboardFocusManager, but maybe there's a better way - I know the JDK folks are doing something noticing app idles, but I don't know if mere mortals can do this too) - On windows, *possibly* also listen for printscreen - *Never* try to reread the system clipboard unless the application has been deactivated (no NB window with focus), with the exception of PrintScreen. There are very, very few cases where the system clipboard contents will ever get updated without the app being deactivated. Adding Trung & David Strupl to cc, Trung's the author of a similar fix in NbClipboard.getClipboardContents() for Linux, David of the patch for 32485. I think this is caused by the fix for issue 32485 - quoting from it, "The only disadvantage of this fix is that the contents of the external clipboard might get converted more than once. Please review - if there is no objections I would apply the patch to the trunk."
Reassigning to core/code - not sure exactly who's responsible for NbClipboard.
I'm raising the priority of this. Try the following on a 1280x1024 screen on Windows: - Press ALT-PrintScreen to make a screenshot of NetBeans main window - (paste it into photoshop or something - probably not necessary step) - Now, in the form editor, simply try to select any node in the component inspector. Changing selected nodes takes +/- 1 minute on a very fast machine. I'm not sure who owns NbClipboard - I can dig into this if nobody else will, but somebody who knows the code better might handle it faster. "AWT-EventQueue-1" prio=7 tid=0x012af998 nid=0xd70 runnable [0x030ef000..0x030efbe8] at sun.awt.datatransfer.DataTransferer.concatData (DataTransferer.java:2038) at sun.awt.windows.WClipboard.getClipboardData(Native Method) at sun.awt.datatransfer.ClipboardTransferable.fetchOneFlavor (ClipboardTransfer able.java:106) at sun.awt.datatransfer.ClipboardTransferable.<init> (ClipboardTransferable.jav a:80) at sun.awt.datatransfer.SunClipboard.getContents (SunClipboard.java:130) - locked <0x62b21018> (a sun.awt.windows.WClipboard) at org.netbeans.core.NbClipboard.getContents (NbClipboard.java:99) - locked <0x62b22a80> (a org.netbeans.core.NbClipboard) at org.openide.explorer.ExplorerActionsImpl.updatePasteAction (ExplorerActionsI mpl.java:279) at org.openide.explorer.ExplorerActionsImpl.updateActions (ExplorerActionsImpl. java:222) at org.openide.explorer.ExplorerActionsImpl.access$400 (ExplorerActionsImpl.jav a:48) at org.openide.explorer.ExplorerActionsImpl$ActionStateUpdater.update (Explorer ActionsImpl.java:639) at org.openide.explorer.ExplorerActionsImpl.updateActionsState (ExplorerActions Impl.java:592) at org.openide.explorer.ExplorerActionsImpl.access$000 (ExplorerActionsImpl.jav a:48) at org.openide.explorer.ExplorerActionsImpl$OwnPaste.getValue (ExplorerActionsI mpl.java:413) at org.openide.actions.PasteAction$ActSubMenuModel.getPasteTypesOrAction s(Past eAction.java:304) at org.openide.actions.PasteAction$ActSubMenuModel.checkStateChanged (PasteActi on.java:407) at org.openide.actions.PasteAction$ActSubMenuModel.propertyChange (PasteAction. java:449) at org.openide.util.WeakListenerImpl$PropertyChange.propertyChange (WeakListene rImpl.java:131) at java.beans.PropertyChangeSupport.firePropertyChange (PropertyChangeSupport.j ava:305) at java.beans.PropertyChangeSupport.firePropertyChange (PropertyChangeSupport.j ava:242) at org.netbeans.core.windows.RegistryImpl.doFirePropertyChange (RegistryImpl.ja va:240) at org.netbeans.core.windows.RegistryImpl.tryFireChanges (RegistryImpl.java:223 ) at org.netbeans.core.windows.RegistryImpl.selectedNodesChanged (RegistryImpl.ja va:175) at org.netbeans.core.windows.WindowManagerImpl.notifyRegistrySelectedNod esChan ged(WindowManagerImpl.java:820) at org.netbeans.core.windows.WindowManagerImpl.topComponentActivatedNode sChang ed(WindowManagerImpl.java:930) at org.openide.windows.TopComponent.setActivatedNodes (TopComponent.java:248) at org.netbeans.modules.form.ComponentInspector$NodeSelectionListener.ru n(Comp onentInspector.java:449) at java.awt.event.InvocationEvent.dispatch (InvocationEvent.java:201) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchThread.j ava:234) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.jav a:163) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:149) at java.awt.EventDispatchThread.run (EventDispatchThread.java:110)
the reason of the slowness on Windows is simple: my NbClipboard hack is activated only on Unix. Try to run the IDE on Windows with runide.exe -J-Dnetbeans.slow.system.clipboard.hack=true If it works, I'll turn the hack on in all cases. BTW the hack is buggy now because Yarda unintentionally commented out a piece of code in NbClipboard. I'll fix it
Trung, is your NbClipboard hack appropriate to turn on by default? I read the code once a long time ago, but haven't looked at it recently.
not the cleanest solution but should be safe. Please test it on Windows and let me know the results
Well, I tested it on Windows, as best I could...and discovered issue 40238 - the paste action is not always properly updated (has not been working correctly since at least December). I saw one exception on JDK 1.5, from the menu UI trying to fetch a color from the parent menu before it exists. That's probably an artifact of JInlineMenu, etc., but could conceivably be related to using -J-Dnetbeans.slow.system.clipboard.hack=true if it affects the timing of when the menu item(s) will be updated. Trung, I haven't seen any commit from you, so I don't know what Jarda commented out, or whether that affects my results. Please point me at the line so I can test it. We're going to need to fix issue 40238 first, so the waters are less muddy before I can meaningfully test the slow clipboard hack. I'll try to figure out what's going on.
> BTW the hack is buggy now because Yarda unintentionally commented out > a piece of code in NbClipboard. I'll fix it fixed yesterday
I'm trying to run the build #200402221900 with the -J-Dnetbeans.slow.system.clipboard.hack=true switch on Windows NT 4.0 and I can't say it works very well for me. I pressed the PrintScreen key to get the screen content into the clipboard. Navigating in Explorer is reasonable responsive (unlike without the switch). However, other actions and especially typing in editor seems to suffer from the same problem. I type a few characters, CPU goes to 100% and the typed characters appear with a long delay. Unless I'm doing something wrong, we need a much better solution I'm afraid.
> However, other actions and especially typing in > editor seems to suffer from the same problem. this is expected bcs the editor is accessing the system clipboard directly not thru NbClipboard. I told Mila about this at the time I made the hack. It's all about if we want to have a standalone editor or just let it go and make all the editor depend on core/openide. The middle ground solution is to build a bridge
200402221900, winXP with the switch the performance in selecting nodes is better but the Editor is almost unusable. Typing/moving in Editor become a nigthmare... More users use Editor frequently than Explorer. part of thread dump - Editor "AWT-EventQueue-1" prio=7 tid=0x03513d08 nid=0x208 waiting on condition [843f000..843fd8c] at sun.awt.datatransfer.DataTransferer.concatData(DataTransferer.java:1970) at sun.awt.datatransfer.ClipboardTransferable.getClipboardData(Native Method) at sun.awt.datatransfer.ClipboardTransferable.fetchOneFlavor(ClipboardTransferable.java:106) at sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferable.java:80) at sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:96) - locked <0x10b36438> (a sun.awt.windows.WClipboard) at org.netbeans.editor.EditorUI$4.run(EditorUI.java:634) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:454) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
The clipboard contents checking was introduced by recent fixing of issue 39678 by Martin Roskanin. Besides that there was no other checking of system clipboard's contents in the past. Unfortunately I reviewed Martin's patch just now and I see that the clipboard contents checking is done after the caret fires change to attached ChangeListeners which is BTW after typing a character into editor. I will change the fix to delegate to NbClipboard so that Trung's hack will be used and the system clipboard will not be examined. BTW personally I would vote for eliminate polls to system clipboard completely at least if there could be a cmd line option for that. The paste action would be enabled all the time but I can easily live with that. The perf would be little better and mainly I would not be affected by the deadlock of http://developer.java.sun.com/developer/bugParade/bugs/4502152.html that I hit once in a couple of days. Opinions?
why we need to poll the clipboard periodically/after each key typing? Doesn't it suffice to check status of Paste action only when the editor gets focus and always enable Paste when the user Copy selected text into the clipboard when she is in the editor? After all when I am in the editor all the time, who else can change contents of my clipboard? Any use case?
We will review the current patch and we can do further improvements like the one that you have suggested. However the editor can be extened by additional actions that can possibly modify the clipboard's content which would break the logic that you've described. On the other hand with your hack the querying of clipboard contents becomes no-op, right? So I'm wondering whether we really need to add an extra editor-side logic that can potentially become imprecise. Anyway we can further discuss the final solution.
FWIW, when I was running with logging, I noticed PrintAction.isEnabled() was being called multiple times for each node change. That may add to the problem, I don't know.
fixed. Avoid calling system clipboard getContents() even on Windows
Tim, could you verify this? Thanks in advance.
OK