martin
I've been thinking about it too, it would be great if they performed similar tests during their reviews. It could allow us, "the affected ones" to check which devices may be fine, which we can't do apart from PWM.

Let me finish the second round of tests (will happen around weekend) which may reveal more issues and as a result provide more details to share with 3rd parties. I'd like to confirm what exactly this observed issue is first. There's still a small chance that it's caught by camera, but is irrelevant to our problems.

    4 days later

    Short news after further tests on W10. I've tried these options (Macbook Pro with Win10 over Bootcamp) on rgb(0,50,0), i.e. deep green in full brightness:
    - Standard view (no modifications)
    - Ditherig on
    - Intel graphics powersaving settings disabled
    - Intel Iris graphics driver disabled in Device Manager (it should equal going to standard VGA driver)

    All of these variants produce the same flicker that can be seen on two videos above. It might be dithering on screen level as neither Ditherig or standard VGA can disable flicker on this thing. Does anybody know if Ditherig should work on Macbook's Iris cards?

    • JTL replied to this.

      andc All of these variants produce the same flicker that can be seen on two videos above. It might be dithering on screen level as neither Ditherig or standard VGA can disable flicker on this thing. Does anybody know if Ditherig should work on Macbook's Iris cards?

      How about trying a REALLY OLD build of Win10? I think the oldest Windows you can install is 8.1 or Windows 10 build 1507.

        JTL So now we're sure that Eyestrain is from Flickering, Flickering is from PWM Rate, or Color Dithering, PWM Rate is from Screen, Color Dithering is from Driver/GPU/Screen. These are all major possible causes, right?

        What is eyestrain:
        Flickering = Eye Muscle Tired cause Eyestrain
        Two flickering source: 1. screen flickering = PWM, 2. pixel flickering = Color Dithering

        EYESTRAIN <- Flickering <- PWM (higher is better)
                                <- Color Dithering (disable it)
                                

          eDenon-2 Plus still unknown type of alleged pixel flicker in specific software/apps/games on otherwise known-good setups. Plus maybe DC ripple. And maybe blue light or other parts of the spectrum (this probably belongs to "brightness").

          andc Thank you for this work. Yes please as suggested try older win 10, like 1511 was reported to be good for pretty much everyone.
          About the 3rd parties sharing, basically you dont need to have complete proof, the point is sending an incentive for them to research this also, they might have better tools.
          Also I cannot believe Intel not only closed the thread about eyestrain as "solved", but they dont even want to share the results. I wrote to the guy asking for the lab results to be published.

          eDenon-2 (maybe) LED Blue Light

          I would change maybe to "yes"

          Ok, I’ll have to try 1511 if it could end up in different results. It will mean I’ll probably have to wipe my instance since there seems to be no easy way of installing 3rd OS on Bootcamp.
          By the way - here’s interesting video I came across through YT recommendation:

          https://youtu.be/3BJU2drrtCM

          These guys seem to have great cameras that can both make a proper zooming in, and film with 100kfps - this should see the actual processing in action, maybe even PWM on Macbooks 😉

          • JTL replied to this.
          • KM likes this.

            andc maybe even PWM on Macbooks

            A good oscilloscope can do that.

            • andc replied to this.

              JTL A good oscilloscope can do that.

              I know it can, but camera would show what really happens, especially how dithering is made on individual pixels level, whether it happens on all the brightness levels, etc.

              cont-temp One thing that I am curious about is that if different color profiles on the macbook change the flickering at all. For example that deep-red with not the default screen color profile (color LCD) but for example with Adobe RGB (1998). And maybe with truetone/nightshift on and off if you have one of the newer versions of OS.

              I checked various color profiles on MacOS yesterday (around 8 of them including Color LCD, Adobe RGB, Universal RGB, sRGB, Display P3). Each of them flickers on static deep-green color (rgb(0,50,0)) - some are better, some are worse, but differences probably come from the actual representation of this color on different profiles - it ranges from standard green (for brighter profiles) to almost black (for darker ones). Turning off font-aliasing didn't stop the flicker. Running Night Shift didn't change it too, although results were a little bit different than I expected - there was no added red subpixel component visible this time, maybe it's too subtle for camera, but I'll have to recheck it.

              I also made a test with shades of gray getting down from 255 (white) to 0 (black) which shows obvious flickering at lower levels.

              Another test I tried is checking how lagom's pixel inversion examples (http://www.lagom.nl/lcd-test/inversion.php) look under the microscope. There weren't any anomalies, they were shown as standard static pixels in different configuration.

              I'll upload shades of gray and lagom's videos later, just for reference, although they don't seem to reveal too much.

              Next step is checking browsers - Firefox Quantum vs. Safari vs. Chrome on MacOS - maybe some differences in font rendering will be easy to be spotted if one of them is using non-standard shading on the edges.

              Edit:
              Here are 2 videos with grayscale and Lagom.nl tests:

              https://vimeo.com/294115665 https://vimeo.com/294115542

              I've checked various webpages in Firefox Quantum (62.0.3), Chrome (69.0.3497.100) and Edge on Win 10/Macbook setup and haven't seen major differences between them so far. I'll try to write another script that will scroll the same way through some example text in different fonts so we can compare them 1-1 between these browsers, current browsing video is too chaotic to be reliable comparison input.

              What's interesting is the fact that every font seems to use some antialiasing stuff, i.e. it isn't just black, but also has some shades on the edges, the bigger the font the wider this shade is. As can be spotted on previous videos - shades equal dithering. And this dithering happens exactly where our eyes try to get focus (at the edges of characters). It may mean that our eye strain may be a result of focusing exactly on things that are constantly changing. I didn't think this shading will be happenning in such extent on retina screen which is quite sharp, but it does.

              • JTL replied to this.

                @andc when you started your research with your MBP 13'' 2015 which OSX version were you using?

                I noticed that I get migraine like symptoms when using OSX 10.13.5 and up (including Mojave). When I reverted the graphics driver to the one in OSX 10.13.4 it got way better (even on Mojave). The blue light is still an issue, but hey, no migraine 😃

                Edit: Ok, Apple does something on 10.13.6 and up that cannot be fixed by reverting the graphics driver. So I need to go back to 10.13.4 (or 10.14.5 with old driver) to get my head straight again...).

                • andc replied to this.

                  deepflame

                  Replied in the other thread. Started having issues after High Sierra on 2015 model. Now as I put it under scope it’s on HS probably, I’ll have to check it since I don’t use it on regular basis.

                  Here is another video: rendering of fonts on W10/Macbook Pro in different browsers: Chrome, Edge, Firefox in current versions (I'll downgrade Firefox to see if it differs later).

                  https://vimeo.com/294862076

                  I ran custom script that scrolled through sets of "S" letters (since it has most curves, so most potential antialiasing would happen) in different fonts, boldness levels, with antialiasing set to on / off, etc.

                  Results may not look groundbreaking, but you should clearly see dithering on the edges where antialiasing (i.e. shading on subpixel level) happens. Actually this is not so big as I saw before on some pages - probably there are worse fonts than the standard ones I used (Courier, Times New Roman, Arial, Verdana, etc.). Also worth noting is the fact that this screen is retina, i.e. pixels are really small, so the same fonts should use more dithering on screens with lower resolution.

                  Next test I'll be preparing is running the same "S" letters in different shades of gray. I've seen that lots of sites (even Ledstrain) use some deep gray instead of black for the color of their main font. So it's likely to dither, although it seems to be black.

                  I think we may start sharing these videos with more experienced guys (i.e. tech, industry contacts) as @martin suggested since further tests will not be likely to reveal more details, the only big step may be finding a setup (OS, driver) that doesn't dither on the screen that flickers usually. I'll be testing early W10 installation soon, but I don't have high hopes.

                  Another video with fonts in different shades of gray (latest Chrome on Win 10 / Macbook Pro 13):

                  https://vimeo.com/294902061

                  Shades range from black - the first one - #000 to light gray - #bbb. Flickering is visible at first only on edges, but when font becomes more gray whole its area starts to flicker. If you're wondering how given color looks like, here is an example: http://jsfiddle.net/scaLtk8u/1/ - see bottom right part.

                  I need to check one more thing - iterate over ~20 shades surrounding the ones that usually flicker.
                  My idea is - if dithering could be stopped with decreased color depth (i.e. resigining from more accurate colors), there should be at least one shade close to dithering ones with which they can be substituted. If none of them is stable then I don't see a chance of finding non-flickering setup with such screen - each deep red, green, or blue, as well as their combinations will flicker, even on 16 colors display.
                  I initially thought that displays use dithering to fill gaps between supported colors (which should be solid), but it looks rather like PWM on subpixel level, where every darker color causes flickering.
                  The worst case scenario is that such screens are actually not 6, 8 or 10 bit, but 1-bit, i.e. capable of displaying only max brightness (pure color) and min brightness (black) as solid dot, and everything inbetween is simply subpixel flickering, same as PWM can be observed on many displays.

                  Edit: I checked the screen again - my script went through around 30 subsequent shades - each of them flickered, there's no stable phase, so every darker color is subject to dithering. I tried also different settings of ditherig.exe, but it didn't help as well in any case.
                  A strange observation was behavior of Chrome, rather an HTML bug than something important for screen itself:
                  on my testpage I have an info panel with white background. When it's present on screen, Chrome shows some kind of banding-like artifact - top 25% of screen has different shade then the rest on specific range of background color (around rgb(0,30,0)). I'm not sure where it comes from, but neither Firefox nor Edge behave the same way. <body> CSS consists just of background color and it isn't uniform. That's just another sign that with Google stuff you may never be sure recently 😉

                    13 days later

                    andc Could you please do one subjective test for me please? When you are looking through the microscope at the display thats causing you issues (flickering subpixels), if you keep looking longer just through the microscope, does it start giving you issues or not? If not, then it would prove that the flicker is not the cause, but the eye fixation is - when there is such a clear outline as individual pixels to focus on, the problem could disappear no matter the flickering. Without the scope then, the eye fixation could be more complicated and thus the issue comes back. Please let me know.

                    • andc replied to this.

                      martin
                      It might be hard to test - since I don't use this Mac on a daily basis I got a little bit immune to this screen, at least on W10, ie. when I used it a lot even 5 minutes could trigger issues, now I can stand 1-2 hours, this doesn't seem to cause long time effects (broken sight for one day, etc.). It was a surprise when I started doing these tests, rendering videos, etc. Maybe it's new W10 which is somehow better than older updates.

                      So I think it would probably tire my eyes faster by looking through the scope, in a physical way. It's a single lens microscope, so different view in each eye could be problematic too.

                      Anyway, do you want to check if issues start to appear due to light coming from the screen, not the focusing on it? Maybe running this notebook as a background "lamp" on a flickering shade and trying to see if I get tired eyes without looking at the screen directly after 30 minutes would be a good test then.

                        andc Yes, that is the point. Im trying to differentiate between the issue possibly caused by flicker and issue caused by eye fixation. It can also be both - flicker plus small pixels and aliasing result in bad eye fixation, while under the scope, the fixation is easy due to clear outlines of pixels being visible. It would also prove (in your case) the dependency on one vs. both eyes as a factor.

                        • hpst replied to this.
                          dev