Community
Participate
Working Groups
There are two situations where the code mining annotations are displayed slowly: - Open a new Java file - Scroll down in a Java file The behavior always is: - First the regular UI is shown - Then the annotations are drawn (annotation by annotation) This is usually quite fast, but it still leads to a "restless" user interface where code is shown at a different place a few milliseconds after scrolling or opening the file. Maybe it would be better if the annotations would not be drawn asynchronously.
(In reply to Juergen Baier from comment #0) > Maybe it would be better if the annotations would not be drawn > asynchronously. That would mean no text would be shown or UI would be frozen until annotations/codeminings are resolved. I don't think that's what you desire.
(In reply to Mickael Istria - away until July 15th from comment #1) > (In reply to Juergen Baier from comment #0) > > Maybe it would be better if the annotations would not be drawn > > asynchronously. > > That would mean no text would be shown or UI would be frozen until > annotations/codeminings are resolved. I don't think that's what you desire. You are probably right. Although it kind of depends on how fast the codeminings are resolved. Maybe the resolve process should occur on startup and cached? I was thinking that e.g. syntax highlighting is also immediately there (at least I could never notice a delay). I guess codminings are more complex than some AST traversal for syntax highlighting, but still. Anyway, I have no idea how these codeminings (a very impressive, super-useful feature - thanks for it!) are implemented or could be optimized, so just ignore my amateurish suggestions :-).
So what's the specific part of it you think it worth a bug here? The fact that text area is moved incorrectly and the interesting line you're reading is moved when codemining show up?
(In reply to Mickael Istria from comment #3) > So what's the specific part of it you think it worth a bug here? The fact > that text area is moved incorrectly and the interesting line you're reading > is moved when codemining show up? Yes, that's right. I'm looking at the screen and my code moves around until all annotations are shown. The worst case are many small methods with calls with multiple parameters. I just tried it again in Eclipse. The most annoying movements are the vertical movements when the method annotations (which show the number of references) are resolved. In this particular case the layout could reserve a vertical line and add the number of references as soon as they are available. But the delay in the display of parameter annotations (the horizontal movement) is also annoying. E.g. when I have a test class with multiple JUnit assertions like assertEquals(expected1, actual1); assertEquals(expected2, actual2); assertEquals(expected3, actual3); assertEquals(expected4, actual4); and I scroll down then I first see the code with annotations and after some time (no idea, maybe 100ms) I see: assertEquals(expected: expected1, actual: actual1); assertEquals(expected: expected2, actual: actual2); assertEquals(expected: expected3, actual: actual3); assertEquals(expected: expected4, actual: actual4); So I get the feeling the code moves around all the time. I think this should be smoother. When I scroll back (over already resolved annotations) everything is super-smooth, no vertical or horizontal movements. It would be nice if I would get this experience right from the start. It is no problem if sometimes the annotations are delayed (so async is okay, I think), but most of the time the code should not move around.
I also wanted to mention that in "that other IDE" there is zero delay. The annotations are there right after the file has been opened, with no vertical or horizontal code movement. I just verified this with a colleague who switched recently. I have a large Java class (6750 lines). When I open this class and scroll until the end of the file I get the following times (just rough wall clock times): - ~15s with method annotations turned on (all other code minings off) - ~9s without method annotations It would be interesting to measure how much additional time for opening that file with pre-calculated method annotations would take (i.e. synchronous display).
One case that I find particularly annoying is formatting. Every time I hit Ctrl-Shift-F the minings will disappear and reappear, which happens almost instantly. However, the editor content will move downwards by one line. By repeatedly formatting I can move all the way to the top of the document, even though no content actually changed. This is also jarring insofar as it gives the impression that content has changed, which might indicate e.g. that I have changed parts of the document that I did not intend to change.
*** Bug 552553 has been marked as a duplicate of this bug. ***
As I wrote in the Bug that now is marked as duplicate to this one, I suggest to add a placeholder/default mining in case the actual one is not yet available. If it is, it can replace the preliminary one. Although an immediate result would, of course, be optimal, that would suffice for me.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
When I am opening a file and scrolling down (fn+cursor down) to the end of the file then I am experiencing layout problems and a bad scrolling performance. But when I then scroll back to the top of the file the performance is very good. So it is only the first time when the IDE sees a piece of code. This suggests that maybe pre-calculating something on file open would improve the user experience significantly.
