text anti-aliasing inconsistent across environments

[onetapinc]

text anti-aliasing inconsistent across environments

[dotneet]

When attaching retina monitor Chromy uses the Jimp library to resize an image.
This behavior produces a different image with between retina and non-retina.

I've added .setDeviceScaleFactor() in v0.5.1 @beta .
This command force Chrome to display in same pixel ratio always.
Currently I have not enough time to test it with BackstopJS.
So I'm not sure this approach works well. But worth to try.

If works, in backstop case, this command would also resolve screenshot performance issue caused by Jimp.

[garris]

How do I use .setDeviceScaleFactor()?

Like this?

chromy.chain()
  .setDeviceScaleFactor()
  .goto()
  ...

Do I need an argument inside .setDeviceScaleFactor()

[dotneet]

.setDeviceScaleFactor(1)

[garris]

And with this set to 1, Jimp will not try to rescale?

[dotneet]

Yes. Jimp is not called after .setDeviceScaleFactor(1) is called.
Resizing is achieved by Chrome's emulation feature.

[garris]

Ok. Will try this and let you know how it goes. Thanks!

[garris]

So, mixed results...

• .screenshotMultipleSelectors() is still failing 😿
• .screenshot() is now working 😺

Hopefully you can apply the same fix to screenshotMultipleSelectors() ?

See images below...

screenshotMultipleSelectors()

---

screenshot()

[garris]

Here is another part of the test.

The actual file dimensions is off. Rounding error or perhaps a bug?

In Backstop, every pixel value is compared, 1:1 file is required. It can not be resampled.

The borders in the image are 1px

[garris]

Hi @dotneet, I wanted to check and see if you have any thoughts about this one?

[dotneet]

Sorry, I've overlooked your comments.

I've improved the process for scaling in v0.5.2@alpha.
Could you test it whether the change fix this problem?

[garris]

nice! Checking right now...

[garris]

@dotneet sadly no -- did not change anything 😢.

Did you observe the above results? Is the processing between the above capture methods different?

[dotneet]

@garris .screenshotMultipleSelectors() uses full screen emulation but .screenshot() does not.
I've arranged test environments and confirmed that the problem is reproduced.
Please wait for next report. But now I'm working on my job so I can't do this soon.

[garris]

Ok. I understand. Best wishes with your work.

I'll wait for your next report. Thank you.

[dotneet]

@garris I've investigated this problem for several hours, but I can't find out a solution.
I think this results is caused by difference of processes that generate an image.
If my thoughts is correct, resolving this problem is very difficult.
With high resolution screen, to generate same resolution results Chrome need to scale down an image by scaling algorithm. On the other side, with low resolution screen, Chrome don't need to scale an image. What Chrome should do is only capturing the image that is displayed on itself.
So, by the difference of processes, these results become different images regardless of same size.

[dotneet]

Possibly I found out the solution!
Please wait some times.

[dotneet]

@garris please try to add '--force-device-scale-factor=1' to chromeFlags. In my environments, this flag resolved the problem.

[garris]

Yes -- this is GREAT! You have discovered the solution to the size ratio problem! 😺

[garris]

...But interestingly... I am so sorry to report a new issue has appeared!

My guess is that monitor color profile is now causing an issue. In this example there is a large green area on the screen. When referenced on my 72ppi monitor and tested with my retina laptop I get the following diff where all areas of color are slightly different...

It seems that chrome-headless delegates to hardware for rendering pretty significantly. Have you seen anything about how "software-only" rendering could be used with chrome?

In the meantime, perhaps changing monitor profiles will help?

[garris]

Thank you for fixing this! I will create a new ticket for the new issue ^^^

[garris]

fixes garris/BackstopJS#504