GNOME Bugzilla – Bug 701628
Very long lines and cpu usage
Last modified: 2020-04-24 15:19:13 UTC
Hello. I've tested this with bluefish 2.2.2, built against gtk+-2.24.17 and later against gtk+-3.4.4, I got the same behavior. I do a lot of css editing, and I found some time ago that base64 images where a problem. And the bigger they were, the bigger the problem was as well. base64 images can result in very long lines, even small images, because bitmap info has to be stored using a subset of ascii (or whatever). So it's not strange that I end with lines with +10,000 columns, sometimes much longer. When I scroll down such a file, the very moment the offending line is about to appear the editor freezes, and I can see gkrellm becoming mad about cpu usage. I can open the same file in nano and scroll as I wish without even noticing a cpu peak. When a CSS file is full of this stuff I just close bluefish and use whatever is at hand instead. I can confirm that this is not specific to CSS highlighting nor to line wrapping being off/on (though if I turn it off, in a subjective appreciation, it seems a bit faster, but still unbearable). A simple test case that can reproduce this bug can be created with this in bash: $ for i in $(seq 0 100); do echo x >> file-with-very-long-line.txt;done; for i in $(seq 0 10000); do echo -n x >> file-with-very-long-line.txt; done; for i in $(seq 0 100); do echo x >> file-with-very-long-line.txt; done Then open the file and scroll down, up, and so on. As a matter of fact, I have tried the Windows build available for download (2.2.2 as well, not to mix things up) and it doesn't exhibit this behavior. I have built bluefish in Gentoo with debug info, so, if you need something in that regard I can try to debug this, but I have not much experience with gdb and I don't know how to start debugging this. If you can guide me I can try to do my best, though. Thanks beforehand for any help :)
Created attachment 246047 [details] Problematic sample text file
thanks for reporting, unfortunately this is a known bug in the gtk textview widget. there is a bugreport for gtk somewhere in bugzilla, but it hasn't been fixed for years. I'm surprised that the windows build doesn't have this problem, it also uses gtk.... it would be interesting to see if the gtksourceview widget, for example used in gedit, has fixed this problem. Possibly they have a workaround that could be used in Bluefish as well.
Well, I wasn't aware of that. I can take a look myself and see if I can dig up something there. I don't know if it's relevant, but I used winxp in vbox, I guess that might make a difference depending on what exactly the problem is with the toolkit. I'll discover that once I get my hands on a real Windows box. But I have no idea when I will get the time for this. Thanks for all the insight though. It will probe helpful when/if I finally look into this. And if that happens I'll report back.
In fact, gedit works without a problem. So, and pelase, forgiven my gtk+ ignorance, would the solution involve migrating from textview to gtksourceview or are they different purpose-wise and should we be looking into porting the desiderable behavior from the later into the former?
Hi, if this ticket is still valid in a recent version of Bluefish, then please report this under https://sourceforge.net/p/bluefish/tickets/ as GNOME Bugzilla is not used anymore by the Bluefish developers - thanks a lot!