Most active commenters

    ←back to thread

    151 points zdw | 13 comments | | HN request time: 0.353s | source | bottom
    1. Sephr ◴[] No.42153013[source]
    Does this mean better motion response times? The M-series MacBook Pro displays have notoriously smeary displays while displaying high-motion content, so this would be a welcome addition.
    replies(5): >>42153030 #>>42153115 #>>42153425 #>>42153692 #>>42154784 #
    2. xattt ◴[] No.42153030[source]
    > latest Cd-free QD films are very efficient, feature as good or better color gamut and better motion performance

    Possibly yes.

    3. brailsafe ◴[] No.42153115[source]
    So far, the answer anecdotally is no, at least not in situations where lit pixels are moved quickly into black areas. In practice, my obnoxious green text black background terminal was kind of gross to scroll, but haven't experimented much with others yet. Playing games has thus far been fine, scrolling in other contexts is fine for practical purposes. Happy to update this if you want after I ruin my new MacBook by experimenting more
    replies(1): >>42153680 #
    4. impure ◴[] No.42153425[source]
    Notebookcheck says no. Their M4 Pro only did 5-10% better than last year which is still bad.
    5. spacedcowboy ◴[] No.42153680[source]
    Hmm.

    I just set up a 4K terminal (542x143 chars) using the 'homebrew' theme (green on semi-transparent black) and did

    prompt% ls -larS RemoteAstrophotography_com-M63-Stellina.zip | awk '{print $5}'

    4514072533

    prompt% cat RemoteAstrophotography_com-M51-Stellina.zip| base64

    ... and it is happily scrolling up the screen, lightning fast, way way too fast to read, and responding instantly to CTRL-Q/S. Seems ok to me.

    replies(2): >>42154298 #>>42154602 #
    6. numpad0 ◴[] No.42153692[source]
    Was phosphor afterglow ever an issue with LCDs? Just wondering
    replies(1): >>42154794 #
    7. glhaynes ◴[] No.42154298{3}[source]
    The response being referred to here is the quickness of the pixels' ability to change.
    8. brailsafe ◴[] No.42154602{3}[source]
    Certainly a clever way to test it. In terms of response, I meant that at least on a fully black background, you should see ghost lines of text between where the line of text was and where it's going, almost like a mouse cursor with a trail
    9. compass_copium ◴[] No.42154784[source]
    It shouldn't make a difference. The film is illuminated by a blue LED and constantly glows uniformly yellow, which is the same mechanism as the white LEDs in a traditional display (blue emitter illuminates yellow phosphor coating). The LCD filters this to make specific pixels and would be more responsible. I worked for a now defunct QD company.
    replies(1): >>42155591 #
    10. compass_copium ◴[] No.42154794[source]
    LCD BLUs have a uniformly glowing background which is filtered by the LCD to make pixels. If there is delay in pixels updating, it would be the LCD causing it.
    replies(1): >>42154992 #
    11. numpad0 ◴[] No.42154992{3}[source]
    aw. of course. Backlight. Filtering. My brain was hallucinating UV emitting LCD with phosphors in place of filters, that's OLED... thanks.
    12. superjan ◴[] No.42155591[source]
    The way I thought LCD/LED displays worked was by RGB filtering a uniform white backlight. Is it only this design that does fosforescence per subpixel? Sounds way more energy efficient.
    replies(1): >>42155882 #
    13. usrusr ◴[] No.42155882{3}[source]
    Oh, phosphorescence per subpixel (instead of flooding all in "white" that was created through phosphorescence from blue in a central place) sounds like an awesome power optimization for where you still want/need subtractive LCD instead of some *LED with additive per-(sub)pixel emitter.

    For those following outdoor sports tech, I wonder if this might be the secret sauce that allowed Garmin to abandon transflective screens in the Edge 1050, which unlike their post-transflective watches is still technically an LCD. (the not secret at all meat of the change is a depressingly massive battery and big loss in runtime, but I suspect that the battery alone isn't enough to explain that the loss isn't even bigger)