Fix WebGL scaling of antialising by pixel ratio

[ianthomas23]

Fixes #13692, the incorrect scaling of WebGL antialiasing by pixel ratio.

The width and height of the canvas used for WebGL rendering is scaled by pixel_ratio:

bokeh/bokehjs/src/lib/core/util/canvas.ts

Lines 71 to 72 in 78d71c2

	target.width = width*this.pixel_ratio
	target.height = height*this.pixel_ratio

whereas the antialias width is constant regardless of pixel_ratio. Following this through the WebGL rendering pipeline shows that this means the rendered antialiasing scales with pixel_ratio, and so is too large for pixel_ratio > 1 such as for retina screen or zooming (which is implemented in chrome dev tools using a larger pixel ratio).

The fix is to scale the antialiasing by dividing by pixel_ratio.

Test code:

from bokeh.plotting import figure, row, show

ps = []
for backend in ("canvas", "webgl"):
    p = figure(width=200, height=150, output_backend=backend, title=backend)
    p.line(x=[0, 1, 2, 3], y=[1, 2, 3, 2], width=5)
    ps.append(p)

show(row(ps))

before the fix on a retina screen (pixel ratio 2) at zoom level 300% (so the pixel ratio seen is 6):

and after this fix:

The fix scales the antialising that is passed to the WebGL vertex shaders. It could be performed in the vertex shaders instead, but then the antialias would have to be a GLSL attribute rather than uniform. Whilst here I realised that the pixel_ratio is passed to the shaders but only used to scale the canvas size, i.e. to remove the pixel_ratio multiple added in canvas.ts above. So I have moved this scaling to BaseGLGlyph instead which means we no longer need to pass pixel_ratio into any of the shaders. It is not a big deal either way, but I think this implementation is a bit simpler and cleaner.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.65%. Comparing base (78d71c2) to head (3344c55).
Report is 2 commits behind head on branch-3.5.

Additional details and impacted files

@@             Coverage Diff             @@
##           branch-3.5   #13783   +/-   ##
===========================================
  Coverage       92.65%   92.65%           
===========================================
  Files             326      326           
  Lines           20734    20734           
===========================================
  Hits            19211    19211           
  Misses           1523     1523           

[mattpap]

I'm not sure if just using .dpr(N) is enough to produce a meaningful test. I think this needs scaling as well, but we don't have an API exposed for this currently, though it's possible at CDP (Chrome Devtools Protocol) level.

[ianthomas23]

Yes, really we should also be scaling the canvas size along with the pixel ratio. But it is meaningful as it is, here is the dpr=3 test image before and after this PR:

The WebGL line is "too blurry" before this change, but one might have to enlarge the images to convince oneself.

[ianthomas23]

I'd happily remove the new test and save the disk space. But if we keep it we can at least identify when it changes and it will lead us back here where there are instructions for a manual test.

[mattpap]

I would like to keep this test, but I would also like to establish if we can make the difference more obvious. I did a little bit of exploration myself and there is a difference when comparing generated images between branch-3.5 and this PR, so this test is indeed valid, though hard on "the naked eye". I tried to enable scaling in CDP, but it doesn't seem to do anything useful. So I suppose this will have to do for now.

[ianthomas23]

It looks to me like the test failures are unrelated.