Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 146321 - Debugging view flickers on tooltip
Debugging view flickers on tooltip
Status: VERIFIED FIXED
Product: debugger
Classification: Unclassified
Component: Java
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Martin Entlicher
issues@debugger
65fixes1-verified
:
: 146978 147821 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-05 13:54 UTC by Petr Cyhelsky
Modified: 2009-02-19 20:39 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Updated testcase (910 bytes, text/plain)
2008-11-03 17:03 UTC, _ gtzabari
Details
Screenshot of allocation stack-trace (37.00 KB, image/png)
2008-11-03 17:04 UTC, _ gtzabari
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Cyhelsky 2008-09-05 13:54:01 UTC
Product Version: NetBeans IDE Dev (Build 200809050201)
Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b14
System: Windows Vista version 6.0 running on x86; Cp1250; cs_CZ (nb)

Observed: The debugging view sometimes flickers(repaints) on interpretation of tooltip when debugging. This is more
visible on tooltips on some objects not on primitive types.
Comment 1 Petr Cyhelsky 2008-09-11 17:38:10 UTC
*** Issue 146978 has been marked as a duplicate of this issue. ***
Comment 2 Martin Krauskopf 2008-09-11 17:44:20 UTC
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..."
Comment 3 Martin Entlicher 2008-09-11 22:00:51 UTC
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).
Comment 4 Martin Entlicher 2008-09-26 18:27:45 UTC
Partially fixed by changeset:   104109:b7b3f2ea0636, at least for long strings this should be an improvement.
http://hg.netbeans.org/main/rev/b7b3f2ea0636
Comment 5 Quality Engineering 2008-09-27 05:42:59 UTC
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.
Comment 6 Martin Entlicher 2008-09-29 15:48:06 UTC
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.
Comment 7 Quality Engineering 2008-09-30 06:08:44 UTC
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.
Comment 8 Petr Cyhelsky 2008-09-30 14:28:23 UTC
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.
Comment 9 Daniel Prusa 2008-09-30 16:51:34 UTC
*** Issue 147821 has been marked as a duplicate of this issue. ***
Comment 10 Martin Krauskopf 2008-10-09 12:28:58 UTC
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.
Comment 11 Martin Entlicher 2008-10-09 16:49:41 UTC
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.
Comment 12 _ gtzabari 2008-10-24 07:26:49 UTC
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.
Comment 13 _ gtzabari 2008-10-24 07:29:22 UTC
Sorry, I forgot to mention. I am seeing this issue under dev build 200810221401 and I have no tooltips showing.
Comment 14 Martin Entlicher 2008-10-24 17:00:20 UTC
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?
Comment 15 _ gtzabari 2008-10-24 21:21:42 UTC
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.
Comment 16 _ gtzabari 2008-10-24 23:12:53 UTC
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.
Comment 17 _ gtzabari 2008-11-02 20:43:17 UTC
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.
Comment 18 Martin Entlicher 2008-11-03 15:21:46 UTC
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?
Comment 19 _ gtzabari 2008-11-03 17:02:47 UTC
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.
Comment 20 _ gtzabari 2008-11-03 17:03:50 UTC
Created attachment 73139 [details]
Updated testcase
Comment 21 _ gtzabari 2008-11-03 17:04:32 UTC
Created attachment 73140 [details]
Screenshot of allocation stack-trace
Comment 22 _ gtzabari 2008-11-03 17:11:12 UTC
I just confirmed with the Netbeans profiler: they are creating and destroying a new thread once a second.
Comment 23 _ gtzabari 2008-11-03 17:19:16 UTC
I filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=6699
Comment 24 Martin Entlicher 2008-11-04 10:53:43 UTC
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.
Comment 25 Martin Entlicher 2008-11-04 15:59:20 UTC
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.
Comment 26 Quality Engineering 2008-11-05 04:36:28 UTC
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.
Comment 27 rbalada 2008-11-14 10:11:29 UTC
Please verify this issue so it can be included in NetBeans 6.5 Patch1
Comment 28 Filip Zamboj 2008-11-14 13:31:32 UTC
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. 
Comment 29 rbalada 2008-11-18 13:47:08 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo