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.
Version: Q-build 200211200100 JDK: 1.4.1 When stepping through Java source code, markers in all higher level call hierarchies are being updated unnecessarily. It appears that this leads to considerable delays on slow computers and may even introduce other instabilities, e.g. lost focus issues. I have experienced several hard-to-reproduce cases where the marker and the cursor on the current level disappeared where it could be successfully resored by clicking on the last (current) link in the debugger console. Also this creates screen flicker which is annoying. Considering the above effects (especially the bug which I have not entered into the system yet), and the perceived simplicity of the fix, I am suggesting a high priorty.
Created attachment 8336 [details] Testcase demonstrating bug
In JPDADebugger implementation is from steping method invoked clearStackTraceAnnotations() that *unconditionally* clears all call site annotations. I guess that in typical scenario all but last one can be reused. Unfortunatelly I have not found the code where new annotations are added. Is it an asynchronous task that debugger steping does not detect it? A callback?
I see there JPDADebugger.updateUINow() that calls JavaDebugger.annotateCallStack(). Is it OK to reimplement the annotateCallStack() to merge old and new annotations and remove the clearStackTraceAnnotations()? Can occure such a situation that updateUINow() is not called at all?
Marian also mentioned that one possible solution is to postpone annotation updates and batch them with 500ms delay. I could work but it must not affect current PC annotation.
In fact 500ms delay strategy is already implemented in JavaDebugger.updateUI(). It means that either batching does not work or step to step actions delay (i.e. F8 F8 keystroke delay) is longer than 500ms. The second case is pretty possible on slow computers. Besides annotation removal is not subject of batching. Only annotation attaching is batched - it guaranties 500ms flicker in all situations! and it also always occures when slowly/moderately stepping a code. To remove 500ms flicker we must batch both removal and adding. To improve performance we should reuse old annotations or cache Location.getLine() if they prove to be expensive operations.
Fast stepping flicker eliminated for step over and step into actions. Going to implement merging to eliminate it for slow stepping too.
Annotation are merged (actually code was in place but its effects were invalidated by explicit call to clearStackTraceAnnotations() from stepping methods). I do not see any flicker anymore.
Dusan please evaluate if this call-stack visualization is desired. Compare it with content of call stack tab in debugger window. I think that such visualization should be by default off. Reopen if you conclude with the same result. Also please evaluate how 500ms delay inpact users experience.
Resolved for 3.3.x or earlier, no new info since then -> closing.