Smooth Scaling Rounding error fix for win32 #62

[amartya4256]

This PR contributes to fixing the implementation of Smooth scaling of the ImageData to get rid of the rounding errors because of multiple scale ups and downs with fractional scale factor. The commit replicates and modifies the DPIUtil::autoScaleImageData method implementation in Image class to adapt the same.

contributes to
#62 and #127

[github-actions]

Test Results

   533 files  ±0     533 suites  ±0   36m 35s ⏱️ + 6m 32s
 4 363 tests ±0   4 348 ✅ ±0   15 💤 ±0  0 ❌ ±0 
16 595 runs  ±0  16 485 ✅ ±0  110 💤 ±0  0 ❌ ±0 

Results for commit 6f78753. ± Comparison against base commit b91e012.

♻️ This comment has been updated with latest results.

[fedejeanne]

We briefly discussed this in the call but I'd like to point it out here again: wouldn't it be better to fix the smooth scaling for all OSes instead of duplicating the logic in Image (which makes it Windows-specific)?

Did you try fixing it for all OSes already? Did something break?

If it's just a matter of risk management, we can simply try and fix it in DPIUtil and test in Linux and Mac too.

[HeikoKlare]

We briefly discussed this in the call but I'd like to point it out here again: wouldn't it be better to fix the smooth scaling for all OSes instead of duplicating the logic in Image (which makes it Windows-specific)?

Can you please share why the solution was to duplicate functionality? We now have the (almost?) same implementation inside Image (on Windows) and inside DPIUtil. No one will know which one to use when, so I would either expect to have the fix done in DPIUtil or to move the implementation to the OS-specific Image classes if there needs to be a difference between them.

[amartya4256]

We need to draw directly using pixel specific implementation and we cannot access that gc::drawImage usign pixels from DPIUtil. Moreover, DPIUtil uses intermediate scale ups ad downs so I moved it to the Image. Another idea will be to move the method to ImageData and call that from DPIUtil. But for that I need an API in ImageData for smooth scaling. (ImageData is in commons)

[HeikoKlare]

But why is that specific to Windows? Shouldn't the functionality then be generally moved into the Image classes?

[amartya4256]

It cannot be completely moved to Image because its not completely specific to Image but also Cursor and a few other places.

[amartya4256]

Better option would be to move the smooth scaling block in the DPIUtil::autoScaleImageData to a new public method in ImageData class. There we can get rid of the rounding error.

[HeikoKlare]

Better option would be to move the smooth scaling block in the DPIUtil::autoScaleImageData to a new public method in ImageData class. There we can get rid of the rounding error.

Doing that in ImageData would be best anyway since there are several consumers using ImageData#scaledTo, which will produce bad results even if smooth scaling is enabled.
In any way, I think the duplication we have now is quite inacceptable. GC#drawImage contains a hack (explicitly marked as such via an according comment), which this change now works around via another hack. So we should at least factor out the common code into DPIUtil and pass the GC-drawing functionality to that common code as a lambda (or, of course, even better move the functionality into ImageData).

[amartya4256]

Then we should revert the commit and I'll create another PR with a new impl.