Remove unnecessary GC.dispose() calls for GCs on Image

[HeikoKlare]

When creating a GC for an image to programmatically draw that image, it is benefical to not dispose the GC before the image, as it allows to repaint the image at whatever zoom it is required as long as the GC is still active. In addition, the image disposes the GC upon its disposal anyway.

The code of the Eclipse SDK (Equinox, Platform, PDE, JDT) and GEF/Draw2D shall be checked for places to improve by removing the GC.dispose() call or by wrapping the implementation into an ImageGcWrapper. I propose to search for these places by looking for callers of the Image constructors Image(Device, Rectangle) and Image(Device, int, int).

I scanned some of the projects already (Platform and GEF/Draw2D) and found the following:

• SWT
  • Image#ImageGcDrawerWrapper
  • Composite#WM_PAINT
• Platform UI:
  • TimeoutDumpTimer
  • ColorSelector#getImageData (JFace)
  • BreadcrumItemDropDown#AccessibleArrowImage#drawCompositeImage
  • ColorsAndFontsPreferencePage#PresentationLabelProvider
• GEF/Draw2D:
  • GhostImageFigure
  • ImageUtilities

Note that the list is incomplete and particlarly misses parts of the SDK (Equinox, PDE, JDT), so fone action item of this ticket should be the search for further places.

FTR: We also discussed to extend the GC/Image implementation to either not dispose a GC on an image at all or to add a (strict) check that an GC on an image is not disposed before the image. The former has the drawback that it would implicitly und unnoticably keep resources/handles alive (such as images copied by the GC operations to be reapplicable). The latter is difficult to implement as a general check because there may be valid cases where you create multiple GCs (one after another) on the same image, so they would need to be adapted in some way to conform to the check. A strict check has the same drawback (but needs to be activated explicitly) but even then you need to have specific knowledge when the printed warning is actually useful/relevant and when it is not. To in my opinion, we should leave it up to the actual detection of blurry images to fix the implementation instead of proactively adding and automatisms or checks here. @akoch-yatta do you agree?

[akoch-yatta]

I agree with the conclusion to rather adapt the usages than trying to solve this internally and probably cause more issues than solve them.