Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are the speeds usable for writing code? #81

Open
Ingvix opened this issue Sep 20, 2021 · 4 comments
Open

Are the speeds usable for writing code? #81

Ingvix opened this issue Sep 20, 2021 · 4 comments

Comments

@Ingvix
Copy link

Ingvix commented Sep 20, 2021

With the proper documentation still in progress, it's a bit hard to find concrete info if things are on a usable level yet. What I'm hoping for is >=6" display on which I could write code on vim with hopefully at least few frames per second with partial update. Preferably grayscale but monochrome could also be acceptable. Is this possible yet?

I'd like to know before I start buying things to make this happen. I also already have an old Orange Pi but from looking over some issue comments it seems there's some demand for CPU power so should I probably invest in some more modern hardware if I were to chase my dreams?

I also noticed on one image that there used to be #PaperTTY@freenode but has it moved somewhere or just stopped existing after the server takeover( or maybe before it)?

@Ingvix
Copy link
Author

Ingvix commented Sep 23, 2021

Ah, and of course, I would like to know not just the frames per second but how fast the changes actually get to the display?

@joukos
Copy link
Owner

joukos commented Sep 26, 2021

Things are quite usable despite messy docs, although that depends quite a lot on the use case. Whether it works for your case depends somewhat on the type of experience you expect/need, ie. if you have a complex graphical IDE where you need to see a mouse cursor, open menus etc. it's awkward to use.

In pure text env, it's not too bad, takes some getting used to, but the most spot-on use case for these is something where you read a lot more than type (like status display, emergency console, newsreader or such). The Pi4 should have more than enough performance to use the display, but due to SPI transfer there is a variable amount of delay depending on the amount of data (with extra work this might be further reduced). Back in the day of dial-up connections things were worse anyway, so if you can write your code eyes closed for the most part, it'll be fine.

To get some idea of the refresh speeds with a 6" HD + Pi4, these two comments may be useful:

Also fairly recently someone built a "pip boy" sort of device using a slower 4.3" display: https://www.youtube.com/watch?v=xMTEZXEDobM. One might argue that in a post-apocalyptic scenario it would be luxurious 🙂 but with coding finding your way around the code rapidly is often more important than the fact that you can type text with okay speed, and in practice that may make it not so fun to use for day-to-day programming. That said, with such restrictions maybe there's also more incentive to learning efficient editing habits, so I think it boils down mostly to whether you really want to have such a display for reasons of power efficiency, optical properties or just because they're quite novel and fun. It's unlikely to make coding any easier at least.

Note that the 6" HD for example has a high DPI and if you were planning to use something like it for actual work, might as well invest in a magnifying glass to see it properly. The newer models with less resolution but more area might be more suitable for that, but the 6" is the largest partial refresh one I've tried for now.

Regarding the IRC channel, mostly I idled there sometimes, but after everything moved to Libera I just haven't yet bothered setting things up again.

@Ingvix
Copy link
Author

Ingvix commented Sep 26, 2021

I guess the use case I was thinking about when I started to look for solutions to have terminal on e-ink was to get some leisurely coding on vim and possibly chatting on weechat done in a sunny park without needing a power-consuming LCD display on high brightness. So I'm not really interested in the VNC feature for this.

On vim, moving around the code can be quite efficient without needing constant refreshing if one knows the ways. Weechat usage could possibly be optimized by some plugin scrolling the buffer down so the latest message(s) is(/are) at the top whenever a chat window is filled. This way the need to constantly refresh the whole window is reduced and most of the time only the area a new message occupies is refreshed.

Comparing the text appearing on the display to the typing noises in that first comment, the data transfer certainly seems fast enough for typing. And seeing that's with a desktop view, the TTY could probably even perform slightly better. I probably wouldn't even need that high resolution.

I wasn't even considering a magnifier before but it does make sense to use analog means to increase the viewable size if you're looking for speed and smaller display means more of it. Though since my use case is a bit on the mobile side, such probably would increase the overal size and weight so that's also something to consider. Not that as DIY project it wouldn't probably end up a bit bulkier than as a professionally produced product but still...

Is there any hope for proper syntax highlighting in the TTY mode? If a display has something like 16 shades of gray I'm thinking in theory there could be at least 3 or 4 distinguishable shades that could be used for the highlighting along with bold, italic and underline if they're supported.

@joukos
Copy link
Owner

joukos commented Sep 27, 2021

Shades in terminal mode shouldn't be much of an issue and might already be implemented in some of the old forks even, just need to have a bit extra to handle the attributes so they look alright. That said, I don't unfortunately have the time to look into it at the moment but it's certainly doable in a motivated evening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants