[Code mining] Editor content jumps around on every save in 4.35

[Philipp0205]

Let's make sure issue is not already fixed in latest builds first.

• I verified I can reproduce this issue against latest Integration Build of Eclipse SDK

The issue is reproducible with Eclipse 4.35.0 Integration Build: I20250209-1800 Unstable!

Steps to reproduce

From a fresh installation and clean workspace:

• Create a class and a method that is used in that class
• Enable code mining and show references
• Enable "build automatically"

You will see the following issue:

code_minings.mp4

I expected: Code mining should not overlap like before.

But got: The overlapping issue with code mining, already present in earlier versions, has worsened in 4.34. Upon closer inspection, it seems that code mining elements are reloaded/repainted twice instead of once, as in versions before 4.33.

This behavior also causes lines to shift, with new lines constantly being added and removed, making code mining unusable in larger projects!

Tested under this environment:

• RHEL 9
• Eclipse 4.35.0

Community

• I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

[iloveeclipse]

@tobiasmelcher : could you please check, I believe you've contributed few changes in this area? The one in question could be 9b78e0f.

The editor content jumps now visible every time a new line is added and file is saved in java editor, before (4.30) it was not that visible.

Without looking into the code/debugger for me it looks like the code minings are painted / re-layouted more times as before, so the effect of jumping editor lines is much more visible or the paint/re-layout operation is longer.

[tobiasmelcher]

sure, I will take a look. Please give me some time to understand the scenario.

[iloveeclipse]

I personally never use code minings because I don't like the "dynamic" behavior of the editor where something changes without asking me doing that, but now playing with different releases from 4.30 to 4.35 master I believe it is really multiple redraws and it is regression in 4.35 to 4.34.

1. Import JavaProjectGenerator project from https://github.com/iloveeclipse/java-project-generator/tree/issue_2786 & run de.loskutov.jpg.Main. It will generate dummy Java code in the same project.
2. Open Foo0 java file and place cursor at the end of line 41
3. Hit "Enter" to create new line and "Ctrl+S" to save the file
4. Observe multiple (at least 2?) repaints of the editor content om 4.35 master:
   https://github.com/user-attachments/assets/abfc00e1-4bbe-4aa5-b792-35f00d0d9a65
5. Import same in 4.34 release and there will be only one (?) repaint (or much faster):
   https://github.com/user-attachments/assets/f6718e9d-f908-49c4-bc67-42953ab9faea

Note, in the videos I've recorded the frame per second was too low so actually 4.34 looks like it has no repaints, but it has at least one. 4.35 does way to much and video shows only half of that, but that is enough I believe.

[iloveeclipse]

So it looks like adding a line to a document and saving it forces more code minings work/artifacts painted in 4.35 compared to 4.34.

[mickaelistria]

So it looks like adding a line to a document and saving it forces more code minings work/artifacts painted in 4.35 compared to 4.34.

Thanks for clarifying that. I hope this can be captured in a test; I suspect we should be able to count the amount of codeMining painted in test code and set up some expectations with JUnit to identify regressions.

[tobiasmelcher]

Could you please test with the change from #2787 ? Is the editor content then still jumping around?

[iloveeclipse]

Could you please test with the change from #2787 ? Is the editor content then still jumping around?

Looks much better now. See also #2788. Feel free to improve tracing, since I'm not familiar with the code I've just added it in two places that I assumed were relevant. The number of redraw printouts is decreased with your pr.