Hacker News Reader

Comment by jcfrei | Hacker News Reader

On a semi-related note: You know what would really get me excited? A GPU accelerated, highly optimized text editor, that could display several gigabytes of text with several thousand columns wide rows, smooth scrolling, zooming and text-highlighting. That would be a real step up from current text editors. The only thing that comes close (that I know of) is still Vim minus the smooth scrolling and zooming. Meanwhile system default text editors often crawl to a near halt when selecting several rows which are a few thousand columns wide.

View on HN

Not exactly what you're looking for (I don't see GPU acceleration being mentioned anywhere(¶)) but you might still be interested in Xi (https://github.com/google/xi-editor).

For what it's worth, there's also a terminal emulator with similar goals (GPU acceleration included): https://github.com/jwilm/alacritty

(¶) Then again, drawing the text is rarely the bottleneck of a text editor (as the sibling post's author correctly points out). It's usually the data structure to represent the text internally and syntax highlighting that have the greatest influence. (Advanced IDE features like syntax checks, linter and indexing aside.)

GPU acceleration would depend on the Xi frontend. I know that xi-win (https://github.com/google/xi-win) uses Direct2D and DirectComposition. DirectWrite is on the CPU, though, AFAIK. It would be cool to hook it up to pathfinder for a full-stack GPU editor, but I'm not sure it would make a huge difference vs CPU+glyph caching.

> DirectWrite is on the CPU, though, AFAIK.

DirectWrite rasterises glyphs on the GPU when used with Direct2D. GPU path rasterisation was Direct2D's killer feature when it was initially released with Windows 7.

You don't need GPU. You need proper algorithms. I'm using EditPad, it works pretty well with big files. I think there are many editors which work good enough. AFAIK Notepad++ can open large files.

I've had issues with Notepad++ and large files, particularly if the file doesn't have frequent line breaks.

Notepad has a hardcoded size limit. Above that it refuses to open the file. I think it's about 300mb.

For me, a large file is bigger than available RAM.

Sublime Text has been using OpenGL/DirectUI to render text since beginning. It's insane fast with its minimap and syntax highlight.

We don’t use GPU acceleration on Windows or Linux, and only on Mac to push pixel buffers to the GPU. All compositing is done in software, and we have our own library for glyph caching.

You know what could open large files? The editor in Visual FoxPro. Because the devs didn't assume to just load it all in memory and call it a day. No, load the piece you need to display, you can go get more from disk if you need it. Without an install in front of me, I'm pretty sure it was limited to 2Gb, though.

I believe memory mapping the file is the way to go.

How does an editor handle loading from disk and updating when someones inserts to the head of a file? Everything needs to be shifted.

You use a https://en.wikipedia.org/wiki/Rope_(data_structure) and not a flat string.

You only flatten the string when it's time to write to disk.

For autosave files make sure to store the changes to the rope, not the full text.

There is a comment somewhere on HN from the guy that wrote the mapping trick that Word (or WordPerfect) invented way back. They were saving changes to the file rather than flattening. I wish I could find it now.

The data structure is called a piece table, if that ids your search.

According to Wikipedia, it looks like Visual Studio Code is using this data structure.

For what is worth, Sublime Text runs on OpenGL[1].

[1]: https://i.imgur.com/u4Hovt1.png

OpenGL is only used on Mac when the screen resolution is detected as fairly high. We use OpenGL because Core Graphics is too slow to copy the pixel buffer to the screen at 60 fps. We don’t, however, composite the interface using OpenGL.

OpenGL is not used on Linux or Windows. Jon explained to me that Sublime Text 1.x (Windows only) was OpenGL, but he ran into so many bugs related to poor drivers that he backed away from OpenGL for ST2 and 3.

What do you mean by zooming? Increasing the font size?

    :nmap + :let &guifont=substitute(&guifont, '\d\+$', '\=submatch(0) + 1', '')<cr>
    :nmap - :let &guifont=substitute(&guifont, '\d\+$', '\=submatch(0) - 1', '')<cr>
    :nmap _ -

With that, you can increase the font size with normal mode +, and decrease it with - or _.

EDIT: By the way, what are you doing that requires handling text files with thousands of columns and gigabytes of text? That sounds very unusual.

Scientific data. Sometimes I forget that a .txt file I'm working with casually in Igor Pro will cause my laptop to seize violently if I accidentally open it with something else.

It's something I would get excited about - not something I absolutely need. In the past decades so much effort has gone into optimizing rendering speeds for computer games or page rendering on browsers while text editors appear to have pretty much stayed the same (rendering wise).

Well, I can understand optimizing rendering speeds for computer games because the general trend has always been wanting ever more realistic graphics.

However, it's surprising to see people want more rendering speed on their text editors, especially to the point that it would excite them. It's something I've never considered them lacking for their purpose. However, that's probably because I've (nearly) never had the need to handle text files with such characteristics (I usually use it for code and configuration files; none get even close to 1MB), and so to me the text editor is among the fastest, lightest programs I typically run.

rch mentioned scientific data. I guess it's a valid point that there are people working with huge datasets in a practical text file format, and if there are people that can work with huge images or videos on their editors, then why can't text editors do the same.

Visual Studio Code’s terminal is GPU-accelerated [0], a work in progress.

[0] https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

You do not need a GPU accelerated or highly optimised text editor.. You simply need an editor that does not load the whole file to memory, and potentially preloads some data for smooth scrolling and zooming. Operations should be done in O(1) storage as well.

Alacritty[1] + vim

1. https://github.com/jwilm/alacritty

Have you tried EmEditor? It handles gigantic files very well, supports CSV editing and more. Two major downsides are: Windows only, not free

Gvim can handle gigabytes of text easily.

VS Code? No joke.

I switched from Sublime to VS Code because it was better at handling giant log files that would kill subl

Really? I have used sublime for years for log files, Atom and other web based editors would just crash. Hard to imagine that JS would be better at handling viewing large text than C++ (which I think the core of Sublime is written in)

Edit: Benchmarks appear to back this up: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

VScode improved support for handling large files. They don’t even load the whole file in buffer. Load and syntax highlight as you scroll. Pretty smart approach.

Visual Studio Code's performance is impressive versus Atom. However, there's always room for improvement and I really hope with the Github acquisition that this next generation Atom project is incorporated: https://github.com/atom/xray

VSCode has a problem when lines have many columns, you are unable to view the end, it can copy them to the clipboard though. I have to wrap when I want to see to the end.

Reply on news.ycombinator.com