[Win32] Correct lifecycle of handles created via GC.getClipping()

[HeikoKlare]

The recent enhancement to avoid the unnecessary creation of GC operations

• [Win32] Avoid unnecessary creation of GC operations  #3318

introduced a regression, which particularly manifests in broken rendering of CTabFolders. For an example in the Manifest editor, see the screenshots below.

The GC's getClipping() operation stores region handles representing the clipping region (potentially at different zooms) that is combined with the passed region object. The handles for that passed region object are created lazy, so that the clipping region handle needs to be stored until that point in time. Otherwise it will leads to failures when lazily creating the handle for the passed region later on. Currently, these handles are stored in the GC operations and in case the GC or its operations are disposed too early, the region filled via a GC.getClipping() call will fail to create a proper region handle.

This change moves the responsibility for managing the lifecycle of the stored clipping regions to the Region instance in which they are used. Copies of that region ensure via reference counting that only the last disposed Region instance consuming the clipping region will dispose the according handle. A regression test for the scenario that the GC is disposed before consuming the Region handle to which the clipping region is applied is added.

This is a forward fix as an alternative to the revert proposed in:

• [Win32] Partially revert unnecessary creation of GC operations #3351

Without this change:

With this change:

[github-actions]

Test Results

  182 files  ±0    182 suites  ±0   25m 59s ⏱️ -4s
4 730 tests +1  4 707 ✅ +1   23 💤 ±0  0 ❌ ±0 
6 854 runs  +6  6 691 ✅ +6  163 💤 ±0  0 ❌ ±0 

Results for commit c4fa26c. ± Comparison against base commit ceaeabf.

♻️ This comment has been updated with latest results.