IDE speed increase suggestion
BlitzMax Forums/BlitzMax Module Tweaks/IDE speed increase suggestion
| ||
| We all know that MaxIDE is painfully slow at highlighting large pieces of codebase. Well, I was just messing around with FrontPage 2003 and was noticing how Microsoft handles the parsing/highlighting of XML code...they are only highlighting the code that's in the current view window, not the *entire code* all at once like the MaxIDE does. So, as you scroll through XML code in the FrontPage editor you see the system quickly highlight what is in front of you...page down and the next section gets highlighted...it only highlights one page at a time (the page currently in view) and it "forgets" any previous code that is no longer on the screen. How hard would it be to implement this into MaxIDE? If you are working with 10,000+ lines of code, then you know how long it takes to load up a piece of code in the current IDE. |
| ||
| There are these little things called "include files". |
| ||
| It's currently impossible since we don't have a platform-independent way to find out which part of the TextArea's content is visible or when this visible part changes. By the way: This is a Windows-specific problem - the Linux version of the TextArea is a *lot* faster... -- Byteemoz |
| ||
| What he said. We need new (cross-platform) GetSliderValue, GetCursorX, GetCursorY commands to do this (and other improvements like highlighting current cursor pos better). Or switch to an alternative cross-platform, or hand-rolled text area... |
| ||
| Or switch to an alternative cross-platform, or hand-rolled text area... Seconded! the win32 text area widget can be a right pain. the gtk2 one might be worth checking out, its quite nice to use is gtk (at least from C) |
| ||
| Yeah, Textarea is pain and buggy! :/ |
| ||
| As it is for the editor, using scintilla would be the wisest decision instead of replacing the GUI while the rest remains as it is (it currently doesn't work very efficient by preparsing everything that is loaded. Thats nearly as worse as the "bad approach" of using RichEdit using the text formating all over with different formatings to make it worse) |
| ||
| this does not seem like *that* hard of a problem my solution in Pseudocode: the IDE tells you what line the cursor is on. with that info we can surmise that the visible chunk of code could only be (at most) n-lines. n=total lines visible. now if the problem is determining the total lines visible on each platform I think it would be safe to fudge it. my IDE at 1280X1024 has 50 lines. so here is the function StartLine = CurrentLine - 100 EndLine = Currentline + 100 ContextHighlight(StartLine , EndLine) |
| ||
| Why not have a graphics canvas for your text area and use hardware accelerated textured quad rendering to draw the text, and then manage the positioning/hilighting/coloring etc yourself. |
| ||
| Highlighting only a certain section is entirely possible. What I'm saying is there's not much point right now, as I'd rather see a *much* better textarea control that can do more useful stuff, than simply shaving 1 second off initial load time. |
   |