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.
Summary: | Editor hint fixes sometimes take a while to remove the hint annotation | ||
---|---|---|---|
Product: | java | Reporter: | _ wadechandler <wadechandler> |
Component: | Hints | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | dalecooper82, gsporar, issues |
Priority: | P4 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
_ wadechandler
2007-08-17 17:36:34 UTC
My use case was using the editor Anotations to add "throws SomeException" to method definition. There were 2 Exceptions to add and as Ctrl+Enter + Enter is fast to do, when I did Ctrl+Enter second time, the first (already "fixed") Exception still showed in the list. Thanks Wade for filing this and doing deeper analysis. Well, I am not sure against which version is the complaint meant: it says that NB6.0 removes the error almost instantly, and that NB5.5 is slow in this regard - I do not think we can (now) do anything in NB5.5 for this. What could be done (for NB6.0, if time permits), is that the Editor Hints API could, when a fix is implemented, remove the corresponding error. Or all errors on the corresponding line - might be a bit trickier though, and also more confusing. Might need some experiments. I do not think that removing annotations before the parser starts is a good idea - the whole file might flicker (the errors would be removed, the non-fixed ones would be put back, and so on). Ok, here is how I understand the report, please correct me if I am wrong. There is nothing we can do for 5.5.x, the complaint is about hints annotations not being removed fast enough after a users chooses to apply the suggested fix. As with any performance issue we need some serious numbers first in order to be able to start optimizing things. From what jlahoda says I understand that there is no obvious problem in the code that we could easily fix. Other users have said the same about 6.0 in the lists as I have mentioned about 5.5. If the system isn't updating the errors directly, and only relying on parsing, then it will inevitably have different times where lag will be greater as it will be more dependent upon the CPU and other resources for performance. If you have an editor hint for a code fix it shouldn't create error prone code, so if it removes the error it should not come back, and as a user can only make a real action at a time, we really don't need to parse the document again on such a change. We can save some resources [CPU, memory, and disk resources here]. If there is another hint or error for the same line then this one should still be visible and shouldn't be removed, I imagine this built into the API, so I don't see why it has to cause flashing of the error marker if both errors would have caused painting in the same region. Think of it as a stack of cards or layers where you draw 3 red squares on top of each other. You pick one off and the color doesn't change. If each annotation isn't asked to paint itself and another API or class does the painting based on whether an icon or some graphics should be painted at point A or B or not then it should know whether there are other objects (in this case annotations) that the given area or line will still be painted over and should update accordingly and not remove the drawing and graphics if it still needs them. As I said, we can remove the one annotation that corresponds to fix that has been implemented. The paragraph about flickering was more about removing all error annotations from the whole file, which I though you were proposing (but reading your comment again, I probably misunderstood this). Sorry if I wasn't more clear on my initial post. Looks like we're on the same page. Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next". NetBeans.org Migration: changing resolution from LATER to WONTFIX |