Make Resources independent of scaling/zoom

[tmssngr]

Currently, Resources like TextLayout or Font have a nativeZoom or zoom value set. This is inconsistent with recent SWT features on Windows of a) monitor-specific zoom (different shells might have different zoom factors) and b) some controls have disabled autoscaling. This causes serious rounding problem like reported in #3461 that can't be worked-around by the SWT user.

IMHO to avoid any zoom-related rounding errors it needs API change to define the Control or GC onto which these resources should work.

Example:

TextLayout textLayout = new TextLayout(gc); // <-- new constructor
textLayout.setFont(font);
textLayout.setText(text);
final Rectangle bounds = textLayout.getBounds();
textLayout.setWidth(bounds.width + widthCorrection);
textLayout.draw(gc, x, y);
textLayout.dispose();

or

TextLayout textLayout = new TextLayout(control); // <-- new constructor
textLayout.setFont(font);
textLayout.setText(text);
final Rectangle bounds = textLayout.getBounds();
textLayout.setWidth(bounds.width + widthCorrection);
textLayout.draw(gc, x, y);
textLayout.dispose();

[HeikoKlare]

Resources are by intent independent from their usage context. They can be reused on/for different Controls, Drawables and the like. Constructors that tie them to specific zoom-dependent entities (like controls) will break this idea and would require a holistic concept of what happens if these resources (created for one usage context) are then used in a different usage context (as allowed by API design). For example, you may create a TextLayout for one control (with a specific zoom) and then use it to draw on any GC (with a different zoom).

The actual problem with TextLayout is that it is currently tied to a specific zoom, which is not the case for the other resource types. Even Font, though having a zoom value, is managed by SWTFontProvider to retrieve the font handle for a Font instance in the zoom it is required for.
So the issue and the intent is framed more widely than it needs to be. With TextLayout we definitely have an issue, but we have no assessment of the overall manifestations yet, so calling for new API without knowing what needs to be fixed is a bit early. We know about the case using getBounds() for setWrapWidth(), which could be solved locally, such as by storing the zoom for which the wrap width was set and using that for later wrapping calculations, or adding a setWrapAtBounds() that fully relieves the user from using the setWrapWidth(getBounds()) pattern by just making the layout wrap at its bounds and have everything else internally. I am still investigating #3461 and have not posted my assessment yet, but will try to do so as soon as possible.