6 ms·

For most reading and writing tasks I think I’d rather have a a monochrome display with much higher DPI with extremely crisp high contrast edges. I hope that kee

For most reading and writing tasks I think I’d rather have a a monochrome display with much higher DPI with extremely crisp high contrast edges. I hope that keeps improving too. Colour is something I’m willing to go without for this type of device. Maybe a single highlight colour would be nice to have as long as the red or yellow pigment occupies the same cell as black, not an adjacent one. A 600 dpi A4 sized tablet would be lovely. It would be a lot harder to get to that effective dot pitch with colour displays. 300 dpi should be the entry level.

Kuinox 5y ago
I want color, to read code, I can't give up on syntax highlighting
- emteycz 5y ago
  I found out that text styling (bold, underline, italic, and different fonts) are more than enough.
  - ectopod 5y ago
    I've seen this in a few software books. It works very well.
  - alpaca128 5y ago
    I've been wondering for a while whether syntax highlighting had a role in certain code style changes. Like the one where open curly brackets were placed at the start of a new line but nowadays are just appended to the end. Without syntax highlighting the older style seems to make more sense as it makes scope delimiters more visible without using colors.
    - emteycz 5y ago
      IMHO it's just preference - at least the last 15 years - but now propagated as a sort of common default/standard with the advent of auto code formatting tools. C# still does what you say (and practically always did - but the Mono people formatted it differently) while Java and JavaScript do the other. Before Prettier, I formatted JS code like C# - I thought it's nicer. Now I use the other because that's what Prettier does and it's usefulness greatly outweighs my preference.
    - int_19h 5y ago
      Putting braces on the same line is the K&R style, which predates Allman style with braces on separate lines. (The original K&R style had the opening brace on a separate line for functions, but I believe this is due to the original syntax for declaring argument types - if you declare them on separate lines, like variables, a distinct { clearly ends the argument block and starts the function body.)
- mannschott 5y ago
  Back in the day™ Think’s Pascal used bold, italics and underlining to do syntax highlighting because the Mac’s screen was black-and-white. It would be a compromise: you can’t encode as much information into the text’s appearance without access to color, but it could be sufficient depending on your requirements.
  - jagger27 5y ago
    I’m thinking of old Visual Studio syntax highlighting where it primarily uses green and blue. Maybe pick one of those like E-ink panels can already do.
  - int_19h 5y ago
    Even further back in the day, the Algol-60 reference language used bold and/or underlining for keywords - handy when all you have is a typewriter: http://www.softwarepreservation.org/projects/ALGOL/report/Algol60_report_CACM_1960_June.pdf http://www.softwarepreservation.org/projects/ALGOL/report/Al... http://www.algol60.org/reports/algol60_rr.pdf http://www.algol60.org/reports/algol60_rr.pdf (Although technically this was actually syntax, not just syntax highlighting, since that's how the reference language distinguished between keywords and identically spelled identifiers.)
- jagger27 5y ago
  That’s a good point. I think one or two colours mixed with font weights and italics could get us pretty far. Response time is a pretty critical metric for me when it comes to coding. I don’t want to have to wait a couple hundred milliseconds to scroll or switch files, so I’m not convinced coding is a great fit for the existing tech. Code isn’t read top to bottom like a novel. That said, hell yes I want less eye strain when coding. I’m sure we can all relate to that.
- chrismorgan 5y ago
  A few years back, I started a new theme that I call “bland”. I kept it at just pure black on pure white, keywords bold, comments italic for a week. After that, I agreed that some colour was useful, so I made strings red, numbers blue and comments green. All nice and high contrast. Since then I’ve added a little more from time to time, e.g. lifetimes in Rust are italic red, and attributes and macros in Rust code were orange for a few months but are now just italic black (though I still use orange for macro_rules $variables), but I’ve kept it all deliberately minimal and ultra-high contrast. I use the same styling (except for the background colour) on my website. I made a bland-dark somewhere along the way that I very occasionally use, also used on my website. I should probably try something radically different again in another different direction soon. There are generally somewhat better options available for semantic highlighting now than there were five or ten years ago.
chrismorgan 5y ago
600dpi A4 means roughly 5000×7000 (35,000,000 pixels). Even 300dpi is 2500×3500 (8,750,000 pixels). The current typical resolution for 10–13″ tablets (A4 is about 14.3″) is 1404×1872, which is 2,628,288 pixels. You’re asking for 13× as many pixels, and 3× as an entry level. However you arrange it, it’s going to use a lot more power and probably need more memory and a more powerful CPU/GPU.
- jagger27 5y ago
  Your math is correct, but the refresh rates are so low that I don’t see it being an issue. Not to mention that by the time said panel is available on the market CPUs and GPUs will be better. Call it 400 dpi? 450, maybe? It doesn’t seem too farfetched to me. Also, there's a huge difference in bandwidth requirements if the display is monochrome. Consider the framebuffer needed for a conventional 8-bit colour depth display at 5000 by 7000 versus a monochrome, two colour, or a grayscale 16 shade e-ink panel. 24 bit RGB: 105 MB 5 bit grayscale: 21.875 MB 2 bit: 8.75 MB mono: 4.375 MB Pair that with a low refresh rate and partial screen updates and it's suddenly not so crazy.
  - chrismorgan 5y ago
    Pairing it with a low refresh rate is admitting defeat. There are already multiple products on the market with full-screen refresh beyond 30Hz; Dasung’s Paperlike is probably the best known, they don’t publish an actual figure but just say it’s almost as high as LCDs; I’ve found one place of no obvious credibility saying it’s about 40Hz. All this is with ghosting, of course. High quality rendering definitely takes longer, and I get the impression from my reading and observations of a real device that bandwidth may play a part in that speed limit. Partial screen updates can go much faster than that; reMarkable 2’s total latency from marker to screen update is around 23ms if I recall correctly, and I suspect (without confirmation) that it’s updating the screen at 200Hz, the sample rate of the marker. In theory, yes, you can go down to 1- or 4-bit colour (and at 600dpi I think going hard monochrome and depending on dithering would be quite acceptable), but in practice software stacks are rather attached to 24-bit and don’t tend to like going below 8-bit. Especially general-purpose stacks—if you build something yourself from the ground up (whatever that means), then sure, you can generally choose your own path. There are certainly paths that make better use of meagre resources, but experience says they’re seldom taken. I think you’re probably underestimating how much power pushing that many pixels and that much screen bandwidth takes. Such a device is feasible (provided they can manufacture a large enough panel with a tiny enough dot pitch), but not straightforward, and will have some significant tradeoffs. I’m not surprised no one’s trying anything even close to it.
moffkalast 5y ago
Or just a refresh rate that isn't what feels like several seconds.
- dredmorbius 5y ago
  Present devices refresh a 2--8 Hz easily. Even high-quality refresh is fast, though there is a prominent transition. With e-ink, there's a distinct difference between paginated navigation and scroll-based, with pagination being strongly preferred. For web browsing, I recommend EInkBro, which provides paginated navigation as a default. For any longer-form Web reading, that's my preference. It's superior even to Pocket's exceedingly poorly-considered pagination mode. The other alternative is to print-to-PDF and display that within an e-book reader. Unfortunately, many websites format poorly in that mode, with text being cut at pagination breaks, or omitted entirely.
dredmorbius 5y ago
Most devices now are in the 200--300 dpi range, monochrome. That's already as good as a mid-grade laserprinter output, and for text is pretty much entirely sufficient, especially in monochrome. Other issues still remain: some ghosting (at higher refresh / lower quality), limited greyscale (4--16 shades in most cases), and generally far lower refresh rates than emissive displays (1--8 Hz seems fairly typical). Yes, you can watch monochrome video, if you want. It's in the "sufficient for a general overview", but not high quality. The place this shows up most especially isn't in video, per se, but on web pages with animations, whether of icons, graphics/charts, or embedded videos. The result is exceedingly distracting at high display quality settings, with a slow, flashing refresh behaviour.

Kuinox 5y ago

I want color, to read code, I can't give up on syntax highlighting

emteycz 5y ago
I found out that text styling (bold, underline, italic, and different fonts) are more than enough.
- ectopod 5y ago
  I've seen this in a few software books. It works very well.
- alpaca128 5y ago
  I've been wondering for a while whether syntax highlighting had a role in certain code style changes. Like the one where open curly brackets were placed at the start of a new line but nowadays are just appended to the end. Without syntax highlighting the older style seems to make more sense as it makes scope delimiters more visible without using colors.
  - emteycz 5y ago
    IMHO it's just preference - at least the last 15 years - but now propagated as a sort of common default/standard with the advent of auto code formatting tools. C# still does what you say (and practically always did - but the Mono people formatted it differently) while Java and JavaScript do the other. Before Prettier, I formatted JS code like C# - I thought it's nicer. Now I use the other because that's what Prettier does and it's usefulness greatly outweighs my preference.
  - int_19h 5y ago
    Putting braces on the same line is the K&R style, which predates Allman style with braces on separate lines. (The original K&R style had the opening brace on a separate line for functions, but I believe this is due to the original syntax for declaring argument types - if you declare them on separate lines, like variables, a distinct { clearly ends the argument block and starts the function body.)
mannschott 5y ago
Back in the day™ Think’s Pascal used bold, italics and underlining to do syntax highlighting because the Mac’s screen was black-and-white. It would be a compromise: you can’t encode as much information into the text’s appearance without access to color, but it could be sufficient depending on your requirements.
- jagger27 5y ago
  I’m thinking of old Visual Studio syntax highlighting where it primarily uses green and blue. Maybe pick one of those like E-ink panels can already do.
- int_19h 5y ago
  Even further back in the day, the Algol-60 reference language used bold and/or underlining for keywords - handy when all you have is a typewriter: http://www.softwarepreservation.org/projects/ALGOL/report/Algol60_report_CACM_1960_June.pdf http://www.softwarepreservation.org/projects/ALGOL/report/Al... http://www.algol60.org/reports/algol60_rr.pdf http://www.algol60.org/reports/algol60_rr.pdf (Although technically this was actually syntax, not just syntax highlighting, since that's how the reference language distinguished between keywords and identically spelled identifiers.)
jagger27 5y ago
That’s a good point. I think one or two colours mixed with font weights and italics could get us pretty far. Response time is a pretty critical metric for me when it comes to coding. I don’t want to have to wait a couple hundred milliseconds to scroll or switch files, so I’m not convinced coding is a great fit for the existing tech. Code isn’t read top to bottom like a novel. That said, hell yes I want less eye strain when coding. I’m sure we can all relate to that.
chrismorgan 5y ago
A few years back, I started a new theme that I call “bland”. I kept it at just pure black on pure white, keywords bold, comments italic for a week. After that, I agreed that some colour was useful, so I made strings red, numbers blue and comments green. All nice and high contrast. Since then I’ve added a little more from time to time, e.g. lifetimes in Rust are italic red, and attributes and macros in Rust code were orange for a few months but are now just italic black (though I still use orange for macro_rules $variables), but I’ve kept it all deliberately minimal and ultra-high contrast. I use the same styling (except for the background colour) on my website. I made a bland-dark somewhere along the way that I very occasionally use, also used on my website. I should probably try something radically different again in another different direction soon. There are generally somewhat better options available for semantic highlighting now than there were five or ten years ago.

chrismorgan 5y ago

600dpi A4 means roughly 5000×7000 (35,000,000 pixels). Even 300dpi is 2500×3500 (8,750,000 pixels). The current typical resolution for 10–13″ tablets (A4 is about 14.3″) is 1404×1872, which is 2,628,288 pixels. You’re asking for 13× as many pixels, and 3× as an entry level. However you arrange it, it’s going to use a lot more power and probably need more memory and a more powerful CPU/GPU.

jagger27 5y ago
Your math is correct, but the refresh rates are so low that I don’t see it being an issue. Not to mention that by the time said panel is available on the market CPUs and GPUs will be better. Call it 400 dpi? 450, maybe? It doesn’t seem too farfetched to me. Also, there's a huge difference in bandwidth requirements if the display is monochrome. Consider the framebuffer needed for a conventional 8-bit colour depth display at 5000 by 7000 versus a monochrome, two colour, or a grayscale 16 shade e-ink panel. 24 bit RGB: 105 MB 5 bit grayscale: 21.875 MB 2 bit: 8.75 MB mono: 4.375 MB Pair that with a low refresh rate and partial screen updates and it's suddenly not so crazy.
- chrismorgan 5y ago
  Pairing it with a low refresh rate is admitting defeat. There are already multiple products on the market with full-screen refresh beyond 30Hz; Dasung’s Paperlike is probably the best known, they don’t publish an actual figure but just say it’s almost as high as LCDs; I’ve found one place of no obvious credibility saying it’s about 40Hz. All this is with ghosting, of course. High quality rendering definitely takes longer, and I get the impression from my reading and observations of a real device that bandwidth may play a part in that speed limit. Partial screen updates can go much faster than that; reMarkable 2’s total latency from marker to screen update is around 23ms if I recall correctly, and I suspect (without confirmation) that it’s updating the screen at 200Hz, the sample rate of the marker. In theory, yes, you can go down to 1- or 4-bit colour (and at 600dpi I think going hard monochrome and depending on dithering would be quite acceptable), but in practice software stacks are rather attached to 24-bit and don’t tend to like going below 8-bit. Especially general-purpose stacks—if you build something yourself from the ground up (whatever that means), then sure, you can generally choose your own path. There are certainly paths that make better use of meagre resources, but experience says they’re seldom taken. I think you’re probably underestimating how much power pushing that many pixels and that much screen bandwidth takes. Such a device is feasible (provided they can manufacture a large enough panel with a tiny enough dot pitch), but not straightforward, and will have some significant tradeoffs. I’m not surprised no one’s trying anything even close to it.

moffkalast 5y ago

Or just a refresh rate that isn't what feels like several seconds.

dredmorbius 5y ago
Present devices refresh a 2--8 Hz easily. Even high-quality refresh is fast, though there is a prominent transition. With e-ink, there's a distinct difference between paginated navigation and scroll-based, with pagination being strongly preferred. For web browsing, I recommend EInkBro, which provides paginated navigation as a default. For any longer-form Web reading, that's my preference. It's superior even to Pocket's exceedingly poorly-considered pagination mode. The other alternative is to print-to-PDF and display that within an e-book reader. Unfortunately, many websites format poorly in that mode, with text being cut at pagination breaks, or omitted entirely.

dredmorbius 5y ago

Most devices now are in the 200--300 dpi range, monochrome. That's already as good as a mid-grade laserprinter output, and for text is pretty much entirely sufficient, especially in monochrome. Other issues still remain: some ghosting (at higher refresh / lower quality), limited greyscale (4--16 shades in most cases), and generally far lower refresh rates than emissive displays (1--8 Hz seems fairly typical). Yes, you can watch monochrome video, if you want. It's in the "sufficient for a general overview", but not high quality. The place this shows up most especially isn't in video, per se, but on web pages with animations, whether of icons, graphics/charts, or embedded videos. The result is exceedingly distracting at high display quality settings, with a slow, flashing refresh behaviour.