On 06/11/2016 02:47 AM, Sébastien Wilmet wrote: > /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).
Sure. O_TMPFILE/unlink() is just handy to avoid leaking filenames. > 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. As long as we can treat them as non-fractional boundaries then this is fine. If not, it just affects the column index, not the line index and somewhat complicates the "what column am I on" question. > 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. This is not true. If it were, I would be able to open gtktextview.c and scroll to the bottom immediately upon restoring cursor position like I can in vim. You are left with either jittered scrolling (when you come across more complex portions of text the layout/draw cost is greater) or you decide to stall until the calculation is far enough that you can animate there smoothly. > 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. Then you had too small of resolution for it to be an issue. It's barely keeping up at 2560x1440 at 1x and even worse at 2x with QHD. The scrolling performance is incredibly timing sensitive. If you have more complex blocks of text, it gets worse. Being off by a ¼ of a millisecond still results in a dropped frame which is jarring. This is exacerbated by the laziness in the pixelcache design. When we have a damage or require a full draw (happened *a lot* until the recent GSV changes I put in place) we need to draw roughly 2x the visible area and all within the time period that the FrameClock normally saw for our normative drawing cost (ie: memcpy). Anything we do to improve this design (instead of replace) will likely result in predicting draws sooner to ensure the FrameClock schedules additional time for drawing. -- Christian _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
