*** Issue 146978 has been marked as a duplicate of this issue. ***

Increasing according to dupe. Balloon evaluation is annoying to use without closing Debugger View before. This seems to
be general problem. Repeating question/problem from the dupe:

  "Actually having Debugger View open all the time (I started just
  now this mode), it blinks all the time during debugger usage
  (balloon evaluation, stepping, watches viewing, ....). Is there
  filed some more general issue that this one? It blinks so much
  that I've 'had to' dock it..."

The flickering can be improved after this change: http://hg.netbeans.org/main?cmd=changeset;node=30f654ed7157

Basically it "blinks" during method invocations and steps (collapse when the method invocation/step starts and expands
again when the method invocation/step finishes). Method invocations are triggered by balloon evaluation, watches and
local variables (with toString() column visible).

Partially fixed by changeset:   104109:b7b3f2ea0636, at least for long strings this should be an improvement.
http://hg.netbeans.org/main/rev/b7b3f2ea0636

Integrated into 'main-golden', will be available in build *200809270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b7b3f2ea0636
User: mentlicher@netbeans.org
Log: #146321 - An attempt to reduce Debugging view flickering during tooltip evaluation. Firing of changes is reduced by atomic computation and cut of long strings. This prevents from firing of changes in between.

Fixed in changeset:   104352:52983a7aec40, the call stack is not refreshed when a thread starts evaluating a method.
It's refreshed afterwards, without a delay, thus it should not flicker.
http://hg.netbeans.org/main/rev/52983a7aec40
Please verify.

Integrated into 'main-golden', will be available in build *200809300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/52983a7aec40
User: mentlicher@netbeans.org
Log: #146321 - The refreshing of call stack triggered by method invocation is suppressed.

It is much better now, although the green highlight(denoting current thread) still repaints visibly on tooltip
evaluation on some objects. But the main issue is verified fixed.

*** Issue 147821 has been marked as a duplicate of this issue. ***

As was mentioned the current thread (greenly highlighted) still flickers. Reopening this issue, since subject is more or
less exact. Priority fits as well (rather P2, quite visible to every user using the feature).
More over stacktrace in Call Stack view is reloaded in the same way and is very visible as well.

Workaround is closing/docking those windows during balloon evaluation.

This becomes mostly annoying when the retrieval of the stack frames takes a long time. It subsequently slows down
stepping, because steps are blocked by the retrieval of stack frames in between.

Visual flickering could be avoided by first loading the stack frames and refreshing the tree afterwards, but this would
not prevent from performance degradation caused by loading the whole stack trace and thus it's not a good solution IMHO.

Refreshing only a part of the tree (just the top most stack frame in case of steps) might be a solution, but it's
implementation needs to be well thought. I'm leaving this for the next version.

A part of this was fixed in 6.5, further tuning is left for 7.0.

target milestone 7.0? mentlicher, every time the watch window refreshes it loses my keyboard focus. I consider that to
be rather critical to fix for 6.5. The visual flickering doesn't bother me so much, the fact that I can't use the
keyboard at all (lose focus once a second) is horrible.

Sorry, I forgot to mention. I am seeing this issue under dev build 200810221401 and I have no tooltips showing.

I was not able to reproduce any loosing of keyboard focus when evaluating something in watches.
I've added several expressions into watches, including e.g. Thread.sleep(5000). It takes some time to process, which
cause re-drawing of the call stack tree in the Debugging window. But I've never lost my keyboard focus and I'm still
able to navigate expressions in Watches.

When I press F7 or F8, the focus is transferred into editor, where the cursor is put on the current line. Don't you mean
this as a focus transfer from Watches?

That's not what I meant. In my case execution stopped on a breakpoint. I then add an expression to the watch window
which returns an object. I then attempted to walk the object fields using the arrow keys. Every second the Debug Window
and Watch Window would repaint and my keyboard focus (the line being highlighted blue to signify where the keyboard
focus is) kept on disappearing.

Take a look at http://bbs.darktech.org/netbeans.swf to see what I mean.

I'm sorry. This bug is *really* bad on my end. If I add certain expressions to the watch window it is literally
impossible for me to expand the nodes regardless of whether I use a keyboard or mouse. I click on the [+] to expand, and
a few ms later the window flickers and the node collapses again. It is extremely frustrating :(

I hope you don't mind but I am increasing the priority to P2 because (in my opinion) this is a loss of major
functionality and I can't see 6.5 shipping with this bug. What can I do to help you reproduce this problem on your end?

I am using dev build 200810221401 against JDK build 1.6.0_10-rc2-b32.

mentlicher,

I'm just curious if you got around to viewing the Flash movie I posted...? Are you able to reproduce this behavior on
your end? FYI, it is also reproducible in Java6 update 10 final.

I've seen the flash, but did not manage to reproduce it yet. :-(
The refreshing is caused by changing the value of "uri.getBaseUriBuilder()". It's not apparent why it's trying to load a
new value.

I've tried to reproduce with a small sample program:

public class ChangingVarWatched {

    private Object[] props = System.getProperties().keySet().toArray();
    private String test = "TEST";
    private Properties p = System.getProperties();
    private Map env = System.getenv();

    public static void main(String[] args) {
        new ChangingVarWatched().test();
    }

    ChangingVarWatched getChangedObject() {
        return new ChangingVarWatched();
    }

    private void test() {
        System.out.println(test);
    }
}

Putting a breakpoint to System.out.println and adding getChangedObject() into Watches, I can scroll by it's elements
without any refresh.

Can you please provide some sample application that demonstrates this problem?

I noticed something funny in my environment. It looks like once a second someone is creating, destroying, or renaming a
thread and this, in turn, causes the Watch Window to flicker. I've updated your testcase so you should now be able to
reproduce this problem on your side.

What really bugs me is that I'm unable to track down who is responsible for this thread. Please take a look at the
screenshot and let me know if you understand this better than me. I suspect this code is actually creating a new thread
once a second (as opposed to simply renaming it) so I really want to report this bug to their respective author.

PS: I am using Glassfish v2u2.

Created attachment 73139 [details]
Updated testcase

Created attachment 73140 [details]
Screenshot of allocation stack-trace

I just confirmed with the Netbeans profiler: they are creating and destroying a new thread once a second.

I filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=6699

gtzabari, thanks for the repro-case. I've reproduced the flickering.
I'm going to find out how the changes in threads trigger the re-evaluation.

Fixed in changeset:   107349:cc542791594a and 107351:209a1e75cbdb

http://hg.netbeans.org/main/rev/cc542791594a
http://hg.netbeans.org/main/rev/209a1e75cbdb

Adding 65fixes1-candidate, if this is successfully verified, it might be considered for 6.5 hotfix.

Integrated into 'main-golden', will be available in build *200811050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/cc542791594a
User: mentlicher@netbeans.org
Log: #146321 - Ignore property change events other than PROP_STATE.

Please verify this issue so it can be included in NetBeans 6.5 Patch1

I tried to reproduce this case as written in earlier post. I used a sample program above and few others to test. I
didn't realize any behaviour like this in last build NetBeans IDE Dev (Build 200811140201). 

thus, VERIFIED. 

I've transplanted the two referred changesets into release65_fixes repository in following way:
http://hg.netbeans.org/main/rev/cc542791594a as http://hg.netbeans.org/release65_fixes/rev/ea7d5baecf1d
http://hg.netbeans.org/main/rev/209a1e75cbdb as http://hg.netbeans.org/release65_fixes/rev/9960e83603b0