[win32] Unify scaling inside Control::setBounds

[akoch-yatta]

This commit unifies scale up results in Control::setBounds. With zoom values not dividable by 100 different result depending on using setBounds(Rectangle) or setBounds(int, int, int, int) were possible. Scaling the bounds always as rectangle solves this limitation.

[github-actions]

Test Results

   494 files  ±0     494 suites  ±0   9m 23s ⏱️ -1s
 4 333 tests +1   4 320 ✅ +1   13 💤 ±0  0 ❌ ±0 
16 574 runs  +1  16 466 ✅ +1  108 💤 ±0  0 ❌ ±0 

Results for commit 8dff732. ± Comparison against base commit 23684ac.

♻️ This comment has been updated with latest results.

[HeikoKlare]

This is part of completing a fix in 2016 (3b55f60) improving the initial HiDPI support (e02d49a) for fractional scale values, which was only applied to according calculations in DPIUtil but not to all consumers that contained the same inaccuracy.

[fedejeanne]

@akoch-yatta this PR caused a regression --> #2003. What was the observable bug that was fixed by this PR? Is it safe to revert?

[akoch-yatta]

@fedejeanne this PRs prevents rendering artifacts that would reappear when reverting. I dont't Out of my mind which ones are prevented by this change

[fedejeanne]

I see. Well, let's discuss next week how to proceed with this since the fix seems broken. I share the idea of using only 1 logic to scale things up/down but maybe some use cases are still using the "old" approach in disguise (i.e. scaling width/height instead of calculating them like DPIUtil::scaleUp(rect, zoom) does) and this leads to #2003 .

If my assumption is correct, we should explore going exactly the other way i.e. changing DPIUtil::scaleUp(rect, zoom) so it uses the "old" algorithm, like this:

public static Rectangle scaleUp(Rectangle rect, int zoom) {
	if (zoom == 100 || rect == null)
		return rect;

	return new Rectangle(DPIUtil.scaleUp(rect.x, zoom), //
			DPIUtil.scaleUp(rect.y, zoom), //
			DPIUtil.scaleUp(rect.width, zoom), //
			DPIUtil.scaleUp(rect.height, zoom));
}

But I need to know which use cases were fixed by this PR in order to validate this proposal.

Thank you, @akoch-yatta !

[HeikoKlare]

fwiw: the mentioned regression should have been fixed via this PR:

• Preserved width/height on scaleUp/Down a Rectangle #2047