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.

Bug 38441 - Large data on clipboard slows node selection significantly
Summary: Large data on clipboard slows node selection significantly
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: _ tboudreau
Depends on: 40238
Blocks: 40263
  Show dependency tree
Reported: 2004-01-06 17:40 UTC by Tim Lebedkov
Modified: 2008-12-22 22:48 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Part of a threads dump (7.01 KB, text/plain)
2004-01-06 17:41 UTC, Tim Lebedkov

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Lebedkov 2004-01-06 17:40:37 UTC
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.
Comment 1 Tim Lebedkov 2004-01-06 17:41:46 UTC
Created attachment 12720 [details]
Part of a threads dump
Comment 2 _ tboudreau 2004-01-06 18:01:39 UTC
The problem is triggered by

trying to update the Paste toolbar/menu action's enabled state.  The
real problem is in:


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

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."

Comment 3 _ tboudreau 2004-01-06 18:03:32 UTC
Reassigning to core/code - not sure exactly who's responsible for
Comment 4 _ tboudreau 2004-02-17 15:10:34 UTC
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 

 - 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 

"AWT-EventQueue-1" prio=7 tid=0x012af998 nid=0xd70 runnable 
        at sun.awt.datatransfer.DataTransferer.concatData
        at Method)
        at sun.awt.datatransfer.ClipboardTransferable.fetchOneFlavor
        at sun.awt.datatransfer.ClipboardTransferable.<init>
        at sun.awt.datatransfer.SunClipboard.getContents
        - locked <0x62b21018> (a
        at org.netbeans.core.NbClipboard.getContents
        - locked <0x62b22a80> (a org.netbeans.core.NbClipboard)
        at org.openide.explorer.ExplorerActionsImpl.updatePasteAction
        at org.openide.explorer.ExplorerActionsImpl.updateActions
        at org.openide.explorer.ExplorerActionsImpl.access$400
        at org.openide.explorer.ExplorerActionsImpl.access$000
        at org.openide.explorer.ExplorerActionsImpl$OwnPaste.getValue
        at java.beans.PropertyChangeSupport.firePropertyChange
        at java.beans.PropertyChangeSupport.firePropertyChange
        at java.awt.event.InvocationEvent.dispatch
        at java.awt.EventQueue.dispatchEvent(
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy
        at java.awt.EventDispatchThread.pumpEventsForHierarchy
        at java.awt.EventDispatchThread.pumpEvents
        at java.awt.EventDispatchThread.pumpEvents
Comment 5 _ ttran 2004-02-18 13:45:29 UTC
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
Comment 6 _ tboudreau 2004-02-18 14:45:49 UTC
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.
Comment 7 _ ttran 2004-02-18 14:55:47 UTC
not the cleanest solution but should be safe.  Please test it on
Windows and let me know the results
Comment 8 _ tboudreau 2004-02-18 15:51:15 UTC
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.
Comment 9 _ ttran 2004-02-21 23:53:08 UTC
> BTW the hack is buggy now because Yarda unintentionally commented out
> a piece of code in NbClipboard.  I'll fix it

fixed yesterday
Comment 10 Jan Chalupa 2004-02-23 12:47:52 UTC
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
Comment 11 _ ttran 2004-02-23 13:02:28 UTC
> 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
Comment 12 Lukas Hasik 2004-02-23 15:13:43 UTC
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]
sun.awt.datatransfer.ClipboardTransferable.getClipboardData(Native Method)
        - locked <0x10b36438> (a
        at org.netbeans.editor.EditorUI$
        at java.awt.EventQueue.dispatchEvent(
Comment 13 Miloslav Metelka 2004-02-23 15:25:57 UTC
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
that I hit once in a couple of days. Opinions?
Comment 14 _ ttran 2004-02-23 15:49:47 UTC
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?
Comment 15 Miloslav Metelka 2004-02-23 16:05:33 UTC
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.
Comment 16 _ tboudreau 2004-02-23 18:36:14 UTC
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.
Comment 17 _ ttran 2004-02-25 10:49:26 UTC
fixed.  Avoid calling system clipboard getContents() even on Windows
Comment 18 Marian Mirilovic 2004-02-26 17:20:08 UTC
could you verify this?
Thanks in advance.
Comment 19 Tim Lebedkov 2004-02-27 17:16:13 UTC