Community
Participate
Working Groups
HTML is unusable for large files, especially when creating a new empty file and pasting (e.g. from Source view in a browser).
Created attachment 13960 [details] Large (67kb) File that chiokes HTML Editor Ignore content ;-)
Confirmed. There is a problem with pasting a moderate amount of content. I've (attempted) to add "pasting" to the abstract, since I think this problem is specific to pasting. If you import the source into a project, and then open/edit the pre-existing file, do you also find performance too slow? If so, that may be a seperate problem. Thanks.
adding "pasting" to summary, since the 'major' part of this defect is for pasting large amounts into editor. While important, this defect won't be fixed in time for M2, since will be part of some major performance enhancing work to be done in a later milestone.
One thing I've found so far is that this particular example file is bad because it has an exceedlying long line (e.g. 60,000 chara!) AND has many errors on that line, cause many annotations to be added to it, which, with current code, causes hundreds (if not thousands) of "redraw events" to be posted to the Display thread. So ... for M5, I'll look at short circuting and have a rule something like "if line if over 1000 characters and already has error annotations, skip any additional ones. While inaccurate, at least won't be unusable. Second, I think there's been some improvements made in base code we can take advantage of so we do not have to add the annocations one at time ... see IAnnotationModelExtension. We will look into that post M5, but pre .7.
I´ve tried the latest integration builds and they are a lot better than WTP 0.7 M4. Still I don´t like that all my non-Java editors (Topstyle Pro, Notepad2, Ultraedit, Scite) are far kinder in their response to this bad file than Eclipse WTP. I guess WTP will stumble across a lot of bad HTML, and it should work on this kindly. After all this code is from an actually application, and I´ve seen far more broken code on the Internet as this. Of course all of the above editors handle this file rather stupidly, but even as a pure text file Eclipse doesn´t like it very much.
Just to update status, since this is a major bug, I've looked into the "quick and easy" fix for m5, but it was not so quick and easy after all. We can improve things some, but may have to wait for base fix to fix these really long line cases completely. Will continue to investigate. See also Bug 35931.
Ok, I've tried, but no progress. My bright ideas for annotatiom improvements didn't help much (might have even hurt 50 msces or so) so obviously needs a lot more analysis. But, I'll take Patrick's kind words in comment #5 that this could be reduced to 'normal' severity, and we'll make it a P3. I appreciate Phil and others have made to improve performance in opening files and reconciling, but think there's many issues with this particular test case ... so its a good test case. Doubt we'll have much more improvement for .7 release, but we will investigating and fixing issues one at a time until this file is as fast as any other. Thanks for the good test case Patrick. If you disagree with anything I've said, about changing severity, let me know. That's really your call.
Changing severity and priority as per comment #7, since thre has been some improvement.
I tried pasting this attachment into our HTML editor for 3.0.5 and 3.1 and the editor seems to be much more responsive. The bug that this depends on has been resolved and we've had some general changes in syntax highlighting over the year. Based on this, I'm resolving this bug.
