Vtk-js: computeDisplayToWorld & computeWorldToDisplay issues on highDPI screens

[mix3d]

There seems to be an issue with the results not accounting for the pixel density of the browser/display. A 400x400 canvas will be 800x800 on a hdpi screen, but to overlay html items in the correct place, the values need to be in the browser's values.

This seems to match issues with #1179

[jourdain]

The display coordinate is really canvas space coordinate and the fact that highDPI change that ratio it is just a side effect.
But you can certainly do the same effect without highDPI. So closing for now as to me it is more application specific.

The linked issue is truly a bug but not really related to computeXToY.

If this is still an issue, please re-open.

[mix3d]

That is incorrect. Display coordinates are NOT the same as canvas coordinates.

[jourdain]

But the width/height are really based on the setSize done on the GLRenderWindow. And that is what we mean by "display" at the vtk level. You will have to do the mapping between browser coordinate and webgl/canvas pixel position.

[mix3d]

Right. But in the example of the text widget (which admittedly is less an issue with the SVG widgets), there was ZERO opportunity in that code example to inject a developer-driven handling of browser-position <-> canvas position, it was ALL in internal code.

[jourdain]

I see what you mean now... But truly the issue is the text widget implementation not the computeDisplayToWorld & computeWorldToDisplay methods as those do what they are suppose to do.

[mix3d]

Then my only gripe is nomenclature / naming semantics, and the conflict between "Display" in the context of web vs desktop app in hdpi environments. "Display" in this case actually being "Canvas", but the naming coming from existing C++ functions.

[jourdain]

Yes exactly.