Use ZoomContext in GC

[HeikoKlare]

We have recently added a ZoomContext object that allows to track both a native and a target/device zoom to the Image class:
eclipse-platform/eclipse.platform.swt#2404

This extension has been adopted in GC to track and use separate zooms inside it's GCData as well (namely nativeZoom and imageZoom):
eclipse-platform/eclipse.platform.swt#2387

In order to streamline this, the GC/GCData shall be adapted to also make use of a ZoomContext object instead of containing two separate zoom values. It shall be validated whether it makes sense to add some zoom-specific functionality to ZoomContext as well (such as converting point/pixel values according to the zoom for specific contexts like fonts or images), such that consumers may access that functionality instead of the raw zoom values.

In any case, the ZoomContext inside Image will probably need to become a non-nested (SWT- and Win32-internal) type.

[fedejeanne]

So your proposal is to:

• Extract ZoomContext into its own file
• Keep it Windows-only (internal API)
• Possibly hide the existence of the zooms behind convenience methods

?

If yes then I consider this issue to be understandable and ergo ready.

[HeikoKlare]

Those may all be realization properties / options, yes.

The goal here should be to make use of ZoomContext also in GC.
Along with that (as it's the second place where we apply it), we may check potentials for further generalization. With that I would also like to at least get an understanding if we could eventually replace every non-API-parameter for a zoom with a ZoomContext and then move all the zoom-related conversions (from Win32DPIUtil) to such a ZoomContext class. There you could, e.g., call ZoomContext#pixelToPointForFont(), so that you do not have to care about which of the zooms to use (native zoom, auto-scaled zoom etc.) as the ZoomContext will properly do it based on the method you call. That would also make it easier to understand for readers of the code what is done without knowing which kind of zoom is required at a specific place. But this second part (beyond adapting GC) is something I would only expect an analysis/estimate for in this ticket, so that we can discuss whether we want to create a follow-up ticket for doing the actual refactoring out of it.