On Sun, Jun 05, 2016 at 12:33:20PM -0700, Christian Hergert wrote: > You wouldn't want to mmap() the whole file, because that would still > limit how large of a file you can open on 32-bit systems. You would want > mapping windows with a page replacement strategy. Once you get this far, > mmap() is simply an optimization over a page/extent read. > > You need to iconv/etc the whole thing sequentially and therefore must > read in the whole file upfront. However, you can do this and then > proceed as normal with the alternate file afterwards (using O_TMPFILE or > tmpfs backed fd).
/tmp is mounted in RAM on some distros, AFAIK. Maybe a better place is ~/.cache/, so opening a 8GB file is feasible (not sure it is useful though, but people coming from Windows expect to be able to use a GUI tool for everything). > Are there situations where the character is larger than a single cell? Yes I think. In French there is æ and œ, those should ideally be displayed as 1.5x the size of a char. Or there is also "…". But those are still entirely readable in monospace. But I think in other languages, there are characters that should take 2x the size of a cell. > > 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. When loading a large file (e.g. 20 MB), we indeed see GtkTextView busy computing its size. But for a file of 10k lines, there is absolutely no problem. In gedit-tab.c, scroll_to_cursor() is an idle function. > The main thing I'd like to learn at the hackfest is what constraints > must we take on to do fast text scrolling with GSK+(GL/Vulkan/etc). This > pixelcache copying on every frame is really hard to optimize. When I was a heavy user of gedit a few years ago (for developing in Vala), I've never seen the scrolling performances as a problem. -- Sébastien _______________________________________________ gtk-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-devel-list
