Integration of SVG Rasterization

[Michael5601]

Right now the proposed feature for SVG rasterization utilizes a new public API type SVGRasterizer (former ISVGRasterizer). The functionality is provided by the class JSVGRasterizer which implements the interface.

We had a discussion here about wether this public API should be replaced by an internal class as SVG support will be integrated in SWT in the long run.

On the other hand the public API allows for low coupling and flexibility if we want to exchange the functionality of the rasterizer without rebuilding SWT. @HeikoKlare also mentioned here that the interface could be internal for now as a compromise which would allow integration of a different rasterizer while avoiding the public visibility.

[HeikoKlare]

I am in favor of making the new API internal (and keep it internal unless there is some requirement for making it public).

Maybe my initial comments on this concern were misleading: I just proposed to separate the interface from the actual service implementation for architectural reasons. It allows to still use SWT without SVG support (and in particular according dependencies), ensured by proper encapsulation in separate bundles rather than just by trying to avoid "invalid"/unnecessary dependencies within a single bundle. And it ensure that one may exchange the rasterizer, e.g., if someone really needs it (for performance reasons or thel ike) or, more likely, if, at some point in time, JSVG may become outdated and we need to implement a new rasterizer based on a different library. Then we can easily exchange the fragment for development, testing, CI, deployment etc. purposes, while a tight integration into the SWT host requires a complete exchange of the host bundle.

But from a pure consumer perspective, we (= Vector Informatik) currently have no need of making the rasterizer exchangeable.

[Michael5601]

I performed the change now by moving SVGRasterizerRegistry and SVGRasterizer into org.eclipse.swt.internal. I will close the discussion as we have a consensus.