On 05.06.2016 22:33, Christian Hergert wrote: > On 06/05/2016 10:35 AM, Sébastien Wilmet wrote: >> For source code, GtkTextView is really not that bad IMHO. Normally >> source code doesn't trigger the very long line problem (and even, this >> problem in GtkTextView is fixable by internal refactorings, although >> nobody tried recently AFAIK). And source code is contained only in very >> small files, it is not a problem to load e.g. 20k lines in memory. > > There are a few things that it is really bad at. > > You have to scan linearly from O..n to determine line height. There are > all sorts of hacks to do this upfront in high-priority idles. It's why I > still can't open a file, and scroll to a line number like 1000 correctly > without retrying a bunch of times. > > If we could sacrifice 100% correct scrollbar correctness (really, its > not that big of a deal) we could avoid this problem. Just estimate by > byte offset the Y position, and make calculated offsets in the Y > position b-tree/treap/index relative to it's parent node.
That could be an interesting feature. Places with dense code (many characters, compared to the number of '\n's) will take longer to scroll through (if each PageDown scrolls N bytes). -- O< ascii ribbon - stop html email! - www.asciiribbon.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
