News for hackers. Stuff that matters.
Re:GDB Frontend with C Pointer Visualization by acqq on Monday February 17, 2020 @06:52AM (#22347031)
> Because we're mostly using emissive displays, and it turns out that trying to imitate what works on paper on an emissive display sucks for long term use

I claim it’s not true. If one would measure The light flux of my screen I’m sure it wouldn’t be higher than that of the paper when reading in good light conditions. I claim that it’s dependent of how one configures his display.

Re:GDB Frontend with C Pointer Visualization by scoutt on Monday February 17, 2020 @09:00AM (#22347715)
Emitting light != reflecting light.

I used to battle too against "dark modes". But I was forced to use VSCode for one project (since a couple of months), and I have to say that I became so used to it that now I want to use "dark mode" everywhere I can. Unfortunately IDEs for embedded like KEIL uVision will never get such feature, and now it's a pain to go back to white background.

Re:GDB Frontend with C Pointer Visualization by acqq on Monday February 17, 2020 @05:12PM (#22351358)
> Emitting light != reflecting light.

No. It's photons, and the photons count is the same for a given flux. If your screen emits more photons, it's because you've set the background light too high. That's that user configurable setting I've mentioned in the first post. If you have problems with reflection of some other light source and you solved it by turning it off and sitting in the dark room, you of course have to reduce the background light of your monitor to match the ambient light conditions.

Re:GDB Frontend with C Pointer Visualization by scoutt on Tuesday February 18, 2020 @03:23AM (#22354373)
Light is light, I know. But reading from e-ink is not as comfortable as reading from an LCD whatever the brightness setting is. There are many reasons, like refresh frequency, angle, etc. I'm sorry I don't have time now, but you can look it up.