[Concept] Proper implementation of autoscale disablement for part of the application

[akoch-yatta]

Background

Currently, autoscaling behavior in SWT is configured globally. However, when performing complex drawing operations on a GC (e.g. as used in GEF), multiple issues have been observed due to rounding errors during up- and downscaling, particularly because coordinates and dimensions are rounded to integers.

In practice, the most reliable workaround has been to completely disable autoscaling for the involved Canvas and letting the consumer take care of scaling up before drawing. This is currently achieved by setting AUTOSCALE_DISABLED to true via Widget#setData and adaptions inside of GEF. However, this mechanism is only available in the Windows implementation and is not exposed through a formal API.

Goal

Define a concept for introducing API support to control autoscaling behavior in scenarios involving GC operations. This includes evaluating:

• Where and how this configuration should be applied:
  At the Widget level? including all children?
  Only for the GC?
  Other potential scopes?

• Whether and how this functionality should be supported across other platforms such as GTK and Cocoa, ensuring consistent behavior and integration.

[HeikoKlare]

How is this one to be processed? I think in the current it's not ready for everyone, so we need to either clarify it so that everyone could start working on it or we directly assign assign it to someone like you, @akoch-yatta, who is familiar with the context.

[HeikoKlare]

One thing that might help is to further roll out the idea of a ZoomContext (with native and scaled zoom) that we have just introduced to image. If methods were able to pass such a ZoomContext instead of a simple zoom, it might be easier to deal with different autoscale zooms in the composite structure.

[HeikoKlare]

Note that Drawable#isAutoScalable() exists and can probably be used as public API for enabling/disabling auto scaling on Control.

[fedejeanne]

To be clear: this issue is about extending the API so that:

1. It's not internal anymore and
2. It's available in all OSes

... correct?

If yes: do the rounding errors also happen on Linux/Cocoa? How do they manifest (blurriness, wrong size, artifacts)?

Linux and Cocoa are not a priority for Vector so I wonder: is this really necessary?