31–36 of 36 posts
Earlier quoted context omitted.
Xi is orders of magnitudes more mature than Phi. You can't compare 76 contributors and 1128 commits vs 1 contributor and 103 commits.
Of course you can compare them. One is way more mature, use that.
My point is it's not like they are intending Phi to replace sublime, they're probably just doing it for fun. Even if they are more serious, they're being honest about its short comings right now.
Earlier quoted context omitted.
I love what Xi's trying to do, but last time I tried the OS X frontend, it was very, very slow on large files. I think the Phi page is just including "current state of editor" as well as "aimed for state of editor" in the README.
We've done quite a bit of performance work, and there's a bit more in the pipeline, especially horizontal scrolling of very large lines. Some of the slowness at the latter is performance bugs in CoreText; we're considering more aggressively working around those. If you're still seeing slow performance, please file an issue.
sublime, for comparison, is very snappy on the file.
i also tried it out on a pathological json file, which is just one line, 429984 characters long. it hung xi for a long time, and when it loaded, was very slow. again, sublime is completely snappy on the file.
probably not worth a bug since i think it's related to long-line support, which i think is already on your radar?
I found it interesting to just glance at the code, having never touched Go (but familiar with SDL). Some day I will find the time hack around in one of these new languages, whether it be Go or Rust or Red or Perl6 .. :) I have some trouble understanding the rationale for using SDL_ttf in an editor implementation, though. Did you just cut shaping, bidirectional text and font fallback as acceptable losses, or is it on…
Earlier quoted context omitted.
Was it? Smooth scrolling like what in Commander Keen was hard. Janky scrolling by one line at a time like a text editor probably wasn't that bad if I recall correctly. I guess I really just meant tedious when I mentioned that kind of work. It's not the kind of usual engineering solution when one first thought about the issue at hand. It breaks most usual assumption about how you solve the problem. It's like when some…
It's slow because if you don't have hardware support you end up moving around fairly large chunks of memory, and if you do it 'smoothly' you end up doing that 10 to 16 times more frequently still! It wasn't rare at all to see text editors not being able to keep up with the keypresses when scrolling up or down.
At 320x200, a monochrome display is roughly 8K, and 320x256 is roughly 10K. 640x400 is roughly 32K, and 640x512 roughly 40K.
At 1MHz like on a C64 on a PAL system (25 full frames per second) you have roughly 40,000 clock cycles as an absolute upper bound.
That leaves you with roughly 5 clock cycles to copy each byte for 320x200 (320x200 was the most the C64 would do). But the graphics chip "stole" roughly every other memory cycle outside of the vertical blank, so you had roughly 20k cycles to both read the instruction stream, read a byte and write a byte. for the entire screen.
Given that the shortest instructions on the 6502-compatible CPUs are a byte and can load/store no more than a byte, even if there were single byte instructions that'd let you meaningfully load/store data (there aren't), the minimum number of memory cycles would be 64K to move a screen full of text, or more than 3 frames. In reality you need much more to manipulate source/destination addresses. It's been too long, but I'd be surprised if you'd get anything useful done in less than 8 frames, or more than 300ms.
Faster CPU's of course quickly makes it better (as do, potentially, specialized instructions that reduce the amount of instruction overhead), even but then you tended to get higher resolution or more colours to go.
E.g. the default Amiga workbench was 640x200 on NTSC and 640x256 on PAL systems, in 4 colours (2 bitplanes) for roughly 32K or 40K for a full screen. At 7.16MHz on a PAL system, you'd have about 174 clock cycles per byte per second, or less than 7 cycles per byte per frame. The 16 bit data bus means you can spend about 14 cycles per 2 bytes, but then again the CPU gets access to at most half the bus cycles, and so you're back to struggling.
The only reason the Amiga's could reasonably copy a full screen of text per frame without resorting to monochrome and/or the lower resolutions, was special hardware support in the form of the blitter.