Fix label cutoff #2381

amartya4256 · 2025-08-05T16:07:18Z

This PR contributes to precise scaling of computation of size inside gridLayout by using float precision. This fixes the issue reported in #2166

Explanation

The issue happens because of the loss of precision while calculating the size of the grid in the GridLayout. The code at first calculates the size of widget in GridData#computeSize. Since the width and height in GridData were stored as integer, the returned Point.OfFloat from Control#computeSize is not fully utilized and the residualX and residualY (the floating pointer values) are lost and only integer is used.

Later this less precision integer value is used to set the bounds of the grid, which leads to wrapping the widget with the wrong size. In case of #2166, that leads to wrapping of the text in the widget while the height of the grid is set thinking that the text doesn't need wrapping.

A simple example for loss of precision:
Let's say a pixel value 223 is set at 150%.
when it is obtained in points by GridData#computeSize, it is 223/1.5 = 148.6667 i.e. 149
When scaled up on GridLayout#layout on child.setBounds, it becomes 149 * 1.5 = 223.5 i.e. 224

Hence, this difference of 1 pixel can have the wrong wrapping effect.
While using float in the layout, the inversibility is maintained. Hence, 223/1.5 = 148.66667 and 148.6666667 * 1.5 = 223

How to test

package org.eclipse.swt.snippets;

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

public class SnippetLabelCutOff {
	public static void main(String[] args) {
		Display display = new Display();


		/* Provide different resolutions for icons to get
		 * high quality rendering wherever the OS needs
		 * large icons. For example, the ALT+TAB window
		 * on certain systems uses a larger icon.
		 */
		Shell shell = new Shell(display);
		PartView partView = new SnippetLabelCutOff.PartView(display);
		partView.postConstruct(shell);
		shell.open();



		while (!shell.isDisposed()) {
			if (!display.readAndDispatch())
				display.sleep();
		}
		partView.preDestroy();
		shell.dispose();
		display.dispose();
	}

	public static class PartView
	{
	   public Display aDisplay;

	   private Composite aMidComposite;

	   private Label aRepairLabel;

	   public Font aNormalFont;

	   public PartView(Display display) {
		aDisplay = display;
	}

	   public void postConstruct(Composite pParent)
	   {
	      FormLayout vLayout = new FormLayout();
	      vLayout.marginHeight = 5;
	      vLayout.marginWidth = 6;
	      pParent.setLayout(vLayout);

	      createResources();

	      createMid(pParent);

	      pParent.pack();
	   }

	   private void createResources()
	   {
	      aNormalFont = new Font(
	            aDisplay,
	            new FontData("Arial", 11, SWT.NORMAL));

	   }

	   private void createMid(Composite pParent)
	   {
	      // MID
	      aMidComposite = new Composite(pParent, SWT.NONE);
	      aMidComposite.setBackground(aDisplay.getSystemColor(SWT.COLOR_WHITE));
	      FormData aFormDataMid = new FormData();
	      aFormDataMid.top = new FormAttachment(0, 0);
	      aFormDataMid.bottom = new FormAttachment(100, 0);
	      aFormDataMid.left = new FormAttachment(0, 0);
	      aFormDataMid.right = new FormAttachment(100, 0);
	      aMidComposite.setLayoutData(aFormDataMid);

	      GridLayout vLayout = new GridLayout();
	      aMidComposite.setLayout(vLayout);

	      aRepairLabel = new Label(aMidComposite, SWT.WRAP);
	      aRepairLabel.setFont(aNormalFont);
	      GridData vRepairLabelGridData = new GridData();
	      vRepairLabelGridData.horizontalAlignment = GridData.BEGINNING;
	      vRepairLabelGridData.verticalAlignment = GridData.CENTER;
	      vRepairLabelGridData.grabExcessHorizontalSpace = true;
	      vRepairLabelGridData.verticalIndent = Math.round(32);
	      aRepairLabel.setLayoutData(vRepairLabelGridData);

	      aRepairLabel
	            .setText(
	                  "Rhe erv fhe eovianae tb orao estnffd rniTaa eultoolte i sssube wreco.");
	   }

	   public void preDestroy()
	   {
	      aNormalFont.dispose();
	   }
	}
}

Before:

After:

depends on #2486

github-actions · 2025-08-05T16:17:09Z

Test Results

320 files - 226 320 suites - 226 17m 54s ⏱️ - 11m 39s
4 144 tests - 287 4 118 ✅ - 296 26 💤 + 9 0 ❌ ±0
8 359 runs - 8 405 8 307 ✅ - 8 330 52 💤 - 75 0 ❌ ±0

Results for commit d7a4725. ± Comparison against base commit fdbb769.

This pull request removes 287 tests.

AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_dollarSign
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_emptyString
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letterA
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16LE_null
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_AsciiLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_Asciiletter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_LotsOfLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letters
…

This pull request skips 17 tests.

org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_Constructor_multipleInstantiationsInDifferentThreads[browser flags: 0]
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_setUrl_local[browser flags: 0]
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_setUrl_remote[browser flags: 0]
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_GlyphMetricsOnTab_Bug549110
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_bug551335_lostStyles
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_clipboardCarryover
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_lineStyleListener_invalidStyles_render
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_lineStyleListener_stylesAndRanges_render
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_lineStyleListener_styles_render
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText ‑ test_setStyleRanges_render
…

♻️ This comment has been updated with latest results.

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridData.java

HeikoKlare

One general question on this: wouldn't it possible or even reasonable to stick to width/height values inside GridData but just make them floats and only use Point.OfFloat for the returns of API methods?
Two reasons for this:

SWT is generally lacking some Size object and, unfortunately, at many places Point is used to represent a size (even though that semantically does not make that much sense). Thus, we usually try to stick to width/height when considering sizes.
It would be less error prone as now if you accidentally use, e.g., size.x instead of size.getX(), you may calculate with a wrong value.

amartya4256 · 2025-08-11T10:43:11Z

One general question on this: wouldn't it possible or even reasonable to stick to width/height values inside GridData but just make them floats and only use Point.OfFloat for the returns of API methods? Two reasons for this:

SWT is generally lacking some Size object and, unfortunately, at many places Point is used to represent a size (even though that semantically does not make that much sense). Thus, we usually try to stick to width/height when considering sizes.

It would be less error prone as now if you accidentally use, e.g., size.x instead of size.getX(), you may calculate with a wrong value.

I agree, I'll make the changes.

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridLayout.java

selundqma · 2025-08-25T08:05:56Z

Hi! Is this fix included in the M3 build released last Friday?

merks · 2025-08-25T08:13:16Z

Given the PR isn't merged, no.

HeikoKlare · 2025-08-25T08:54:53Z

The necessary change was too risky to do that late (M3) in the development cycle, so it will not go in the upcoming 2025-09 relesae. We plan to process it as early as possible for 2025-12 M1.

amartya4256 · 2025-09-01T15:11:06Z

@HeikoKlare converted the fields back to float instead of Point.OfFloat and refactored as needed. Please have a look.

HeikoKlare

If I am not mistaken, this change breaks the calculations inside GridLayout, as previous integer divisions and remainder calculations are simply changed to float arithmetics even though the considerations of int division remainders seems to be wrong there.

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridData.java

HeikoKlare · 2025-09-03T09:34:12Z

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridLayout.java

+							float equalWidth = (w + spanWidth) / hSpan;
+							float remainder = (w + spanWidth) % hSpan;


Doesn't this calculation break given that this is no integer division anymore (applies to subsequent places as well)? The equalWidth wil now contain an exact division value but remainder still contains the remainder as if doing an int division.

I looked at the logic and I realized, it was only done to regularize the size of grid cells. But now they we have size in float, we do not need to calculate remainder and we can get rid of it. I tested the code and it seems fine to me. I'll update the code here so that you can review that.

HeikoKlare · 2025-09-03T09:36:38Z

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/graphics/Point.java

+	public static Point.OfFloat from(Point point) {
+		if (point instanceof Point.OfFloat pointOfFloat) {
+			return new Point.OfFloat(pointOfFloat.getX(), pointOfFloat.getY());
+		}
+		return new Point.OfFloat(point.x, point.y);
+	}


This is a duplication of the method in FloatAwareGeometryFactory, isn't it? Shouldn't that be streamlined in an OS-independent way?

With vi-eclipse/Eclipse-Platform#320 we wanted to provide such utility methods directly inside rectangle and point since, they are platform independent. FloatAwareGeometryFactory is a private class inside Win32DPIUtils. Do you think it makes sense to keep using that or maybe we should move towards Point.from and Rectangle.from.

For now I can use FloatAwareGeometryFactory and create a PR following the refactoring as suggested. What do you think?

I mean that we should not introduce duplicated code unnecessarily. If we introduce this method as proposed, we can remove the according method from the FloatAwareGeometryFactory.

Let's do that separately. I would also need to adapt other places. For now I'll remove this from here and use the Factory method. And I'll refactor everything in the next PR. Sounds good?

Does that work? The factory is win32-specific while this is OS-independent code.

I don't get what you mean.

I mean why is it important where GridLayout is located for the part about FloatAwareGeometryFactory and Win32DPIUtils? A Layout Manger shold never need to know anything about DPI scaling and alike...

Please read my comment above. Everything should be in there: it does not make sense (and technically you cannot even) reference OS-specific code from an OS-agnostic class (like the layout-related classes).

@HeikoKlare I read the comments but they do not explain why GridLayout now needs to use Point.OfFloat and be rewritten in using internal API now, so for me it means EVERY LayoutManger now needs to be potentially be rewritten as well (what could be code outside of SWT as well).

As LayoutMangers should already work on the "points" and not the "pixels" so something seems fundamentally wrong here!

And while I can understand that there might be some slight rounding errors, the example above shows a noticeable cut-of that can not be explained by a sub-pixel rounding error to me!

@HeikoKlare I read the comments but they do not explain why GridLayout now needs to use Point.OfFloat and be rewritten in using internal API now, so for me it means EVERY LayoutManger now needs to be potentially be rewritten as well (what could be code outside of SWT as well).

Yes, that might be the case.

As LayoutMangers should already work on the "points" and not the "pixels" so something seems fundamentally wrong here!

As we know, points are imprecise because of their limitation to integers and according rounding errors.

And while I can understand that there might be some slight rounding errors, the example above shows a noticeable cut-of that can not be explained by a sub-pixel rounding error to me!

It is such an off-by-one rounding error.

It is such an off-by-one rounding error.

It does not really look like being of by a few pixels. For me it looks like more the reported size of the label is smaller than it actually should, so the Label class needs to be fixed (or the Point/Rectangle) to not round down but round up instead so in such case we get a slightly larger size (and maybe show a tiny little extra whitespace) than one that is too small. This would then fix the issue for many other cases as well instead of trying to "fix" all callers.

HeikoKlare · 2025-09-03T09:37:50Z

bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Label.java

@@ -179,7 +179,7 @@ static int checkStyle (int style) {
 	if (hHint != SWT.DEFAULT) height = hHint;
 	width += border * 2;
 	height += border * 2;
-	return new Point (width, height);
+	return new Point.OfFloat (width, height);


Why is this necessary? The calling method seems to the wrap the point into an OfFloat (via Win32DPIUtil#pixelToPoint()) anyway, doesn't it?

It won't if the passed object is not OfFloat. Since we want to have precision scaling here, we need to return it as OfFloat so that the scaling method uses the OfFloat scaling. We have such behavior in Win32DPIUtil#pixelToPoint() because we did not want to enable OfFloat scaling SWT wide, because we had problems in some widgets if you remember. Hence, we decided to enable is specifically for those where it is needed. Which means those methods need to return an OfFloat variant to enable themselves for precision scaling.

We would enable it for SWT wide once we have figured out the issues with problematic implementations. We have separate issue for that. One of them being vi-eclipse/Eclipse-Platform#303

Sorry, I don't get it. Control#computeSize() calls Win32DPIUtils.pixelToPoint():

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Control.java

Lines 618 to 624 in 1ae0e18

public Point computeSize (int wHint, int hHint, boolean changed){

checkWidget ();

int zoom = getZoom();

wHint = (wHint != SWT.DEFAULT ? Win32DPIUtils.pointToPixel(wHint, zoom) : wHint);

hHint = (hHint != SWT.DEFAULT ? Win32DPIUtils.pointToPixel(hHint, zoom) : hHint);

return Win32DPIUtils.pixelToPoint(computeSizeInPixels(wHint, hHint, changed), zoom);

}

And that method returns a Point.OfFloat if zoom is not 100:

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/internal/Win32DPIUtils.java

Lines 116 to 123 in 1ae0e18

public static Point pixelToPoint(Point point, int zoom) {

if (zoom == 100 || point == null) return point;

Point.OfFloat fPoint = FloatAwareGeometryFactory.createFrom(point);

float scaleFactor = DPIUtil.getScalingFactor(zoom);

float scaledX = fPoint.getX() / scaleFactor;

float scaledY = fPoint.getY() / scaleFactor;

return new Point.OfFloat(scaledX, scaledY);

}

Sorry, you are right. The behaviour I explained earlier is only valid for Rectangle, not for Point. My bad. Yes we can just return Point.

This commit adds Rectangle.OfFloat.from and Point.OfFloat.from methods and removes the Win32DPIUtils.FloatAwareGeometryFactory class to make these methods OS-independent.

laeubi

Layouts have always operated on whole "points" and requiring one specific layout manger for correct function seems totally wrong to me.

So I miss the following:

A general description why the issue happens at all and fractions of a point make a difference now
What are the plans to potentially test (and fix) other layout mangers as well
How we expect custom LayoutMangers out in the wild to adapt here if the float based API is still not public.
I miss test-cases that testing the new GridLayout behaviour

From the referenced issue it more seems that a relay-outing is missing here and wrapping should instead happen.

HeikoKlare · 2025-09-04T13:49:53Z

A general description why the issue happens at all and fractions of a point make a difference now

I agree that the description needs to be extended to make it easier to understand for everyone (and document for ourselves) what's going on. @amartya4256 please do so.

What are the plans to potentially test (and fix) other layout mangers as well

We plan to do that. Sorry that we did not create a public issue for it so far. We have it in our backlog:

Analyze: Layout:layout behaviour for different zoom level leading to scaling errors vi-eclipse/Eclipse-Platform#391

How we expect custom LayoutMangers out in the wild to adapt here if the float based API is still not public.

Let's do one step after another. We will check the other layouts with the above mentioned ticket and see what problems we can expect in general. We have not experienced any issues with any layout but the GridLayout so far. And then it may be up to providing guidelines for others to adapt and potentially making the float-based API public.

I miss test-cases that testing the new GridLayout behaviour

Yes, adding test cases for problematic cases definitely makes sense. @amartya4256 please do so.

From the referenced issue it more seems that a relay-outing is missing here and wrapping should instead happen.

That's not the case. If it was that easy, we would already have solved it like that.

laeubi · 2025-09-04T13:55:15Z

We have not experienced any issues with any layout but the GridLayout so far

GridLayout gives bad result on Label changes anyways but that's a known issue. In any case a LayoutManger must be sure it can trust the reported size, so as mentioned above I more see this as a bug of the Label (and probably others) to report a wrong size, so I would first look at that issue.

In general a call to the size should report the size the component would need for the given constrains. This might not always be sufficient to show the component if constraints are to small, but given we pass in -1, -1 here it should never be too small!

laeubi · 2025-09-04T14:08:14Z

Taking a quick look at the current implementation.

I think using Math.round() is wrong here for width/height because it will give a possible too small size for components being reported. Instead for width/height one would need to use Math.ceil (I think we can ignore negative numbers here) to never report a smaller size. or one would even need to introduce some rounding mode so the caller can decide an what it want to lean to.

For Point.OfFloat that is often used to measure size, I also thing it would be more safe to use Math.ceil for positive values and Math.floor for negative values instead of Math.round(). In any case I think there should be a small testcase that document (and tests!) the different rounding of "subpoint" values.

amartya4256 · 2025-09-05T11:00:41Z

I have updated the description. When it comes to tests, testing this whole issue in GridLayout as a whole is difficult as nothing is exposed as an API and the problem happens when the pixels values are wrong and not in point values. It all depends on if we have Point object or Point.OfFloat object. And testing the inversibility of pixel to point to pixel is already there in org.eclipse.swt.tests.win32.Win32DPIUtilTests.scaleDownscaleUpPointInvertible() and org.eclipse.swt.tests.win32.Win32DPIUtilTests.scaleDownscaleUpRectangleInvertible().

And on top, I can use the snippet on top as an example that shows how the label cuts off on master but this PR fixes it. Is that enough? @HeikoKlare

laeubi · 2025-09-05T12:29:34Z

@amartya4256 Your example is not really intuitive to me.

You argue that the value without using floats is actually larger than it should (what is somehow expected) but why should setting it to a larger width should trigger wrapping here what should happen when the label is actually smaller so I suspect it is the other way round.

This is even reproducible under Linux GTK by modify the example with

aRepairLabel = new Label(aMidComposite, SWT.WRAP) {
	    	  @Override
	    	public void setBounds(int x, int y, int width, int height) {
	    		super.setBounds(x, y, width - 1, height);
	    	}

	    	  @Override
	    	protected void checkSubclass() {
	    	}
	      };

then the label wraps because I set a bound 1 pixel to small, but if I change it to +1 pixel (or even +10 pixels) it does not wrap.

This commit contributes to enable GridLayout:layout to utilize float values in GridData to calculate precise size on scaling using Point.OfFloat APIs. contributes to eclipse-platform#2166

amartya4256 · 2025-09-08T13:27:43Z

@amartya4256 Your example is not really intuitive to me.

@laeubi I had a look at the snippet itself and found the following difference in the behavior after comparing this branch with master:
On Master:

The label computes its size in pixel in GridData to be (659, 25) in Point.OfFloat
The pixels to point conversion is (439.33, 16.67) in Point.OfFloat but since GridData uses Point APIs, it is considered as (439, 17).
Later, child.setBounds is called in GridLayout.layout which sets the size Point(439, 17) in points.
The scaled value is (658, 25).
Here, the label shrinks by a pixel of width on scaling leading to wrapping of the text but the height remains the same.
(659, 25) -> (439, 17) -> (658, 25)

On this branch:

The label computes its size in pixel in GridData to be (659, 25) in Point.OfFloat
The pixels to point conversion is (439.33, 16.67) in Point.OfFloat.
Later child.setBounds is called in GridLayout.layout which sets the size Point.OfFloat(439.33, 16.67) in points.
The scaled value is (659, 25).
The label is set with the same size it had computed hence, the scaling is more precise and no faulty wrapping occurs.
(659, 25) -> (439.33, 16.67) -> (659, 25)

laeubi · 2025-09-08T14:27:43Z

@amartya4256 that makes much more sense here, and that's why I would suggest to round up any values that represent a width/height. In general I think this can only solved consistently with something like this:

Create a new more semantic API to measure Controls and set their bounds #2488

amartya4256 force-pushed the amartya4256/fix_label_cutoff branch 2 times, most recently from 4e2fcda to fc7dedf Compare August 6, 2025 08:43

amartya4256 changed the title ~~Amartya4256/fix label cutoff~~ Fix label cutoff Aug 6, 2025

amartya4256 marked this pull request as ready for review August 6, 2025 11:26

amartya4256 linked an issue Aug 6, 2025 that may be closed by this pull request

Labels are cut off by autoscaling vi-eclipse/Eclipse-Platform#371

Open

amartya4256 mentioned this pull request Aug 6, 2025

Analyze: Layout:layout behaviour for different zoom level leading to scaling errors vi-eclipse/Eclipse-Platform#391

Open

arunjose696 reviewed Aug 8, 2025

View reviewed changes

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridData.java Outdated Show resolved Hide resolved

arunjose696 reviewed Aug 8, 2025

View reviewed changes

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridData.java Outdated Show resolved Hide resolved

HeikoKlare reviewed Aug 8, 2025

View reviewed changes

fedejeanne reviewed Aug 12, 2025

View reviewed changes

bundles/org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout/GridLayout.java Outdated Show resolved Hide resolved

amartya4256 force-pushed the amartya4256/fix_label_cutoff branch from fc7dedf to b0d972e Compare September 1, 2025 15:08

HeikoKlare requested changes Sep 3, 2025

View reviewed changes

amartya4256 force-pushed the amartya4256/fix_label_cutoff branch 3 times, most recently from e536441 to 2c7ad44 Compare September 4, 2025 10:03

Add OfFloat.from methods in Point/Rectangle

e071469

This commit adds Rectangle.OfFloat.from and Point.OfFloat.from methods and removes the Win32DPIUtils.FloatAwareGeometryFactory class to make these methods OS-independent.

amartya4256 force-pushed the amartya4256/fix_label_cutoff branch from 2c7ad44 to 81790ee Compare September 4, 2025 10:23

laeubi requested changes Sep 4, 2025

View reviewed changes

Use Float in GridLayout for precise scaling

d7a4725

This commit contributes to enable GridLayout:layout to utilize float values in GridData to calculate precise size on scaling using Point.OfFloat APIs. contributes to eclipse-platform#2166

amartya4256 force-pushed the amartya4256/fix_label_cutoff branch from 81790ee to d7a4725 Compare September 8, 2025 13:18

		float equalWidth = (w + spanWidth) / hSpan;
		float remainder = (w + spanWidth) % hSpan;

	public Point computeSize (int wHint, int hHint, boolean changed){
	checkWidget ();
	int zoom = getZoom();
	wHint = (wHint != SWT.DEFAULT ? Win32DPIUtils.pointToPixel(wHint, zoom) : wHint);
	hHint = (hHint != SWT.DEFAULT ? Win32DPIUtils.pointToPixel(hHint, zoom) : hHint);
	return Win32DPIUtils.pixelToPoint(computeSizeInPixels(wHint, hHint, changed), zoom);
	}

	public static Point pixelToPoint(Point point, int zoom) {
	if (zoom == 100 \|\| point == null) return point;
	Point.OfFloat fPoint = FloatAwareGeometryFactory.createFrom(point);
	float scaleFactor = DPIUtil.getScalingFactor(zoom);
	float scaledX = fPoint.getX() / scaleFactor;
	float scaledY = fPoint.getY() / scaleFactor;
	return new Point.OfFloat(scaledX, scaledY);
	}

Fix label cutoff #2381

Are you sure you want to change the base?

Fix label cutoff #2381

Conversation

amartya4256 commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation

How to test

Uh oh!

github-actions bot commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

Uh oh!

Uh oh!

HeikoKlare left a comment

Choose a reason for hiding this comment

Uh oh!

amartya4256 commented Aug 11, 2025

Uh oh!

Uh oh!

selundqma commented Aug 25, 2025

Uh oh!

merks commented Aug 25, 2025

Uh oh!

HeikoKlare commented Aug 25, 2025

Uh oh!

amartya4256 commented Sep 1, 2025

Uh oh!

HeikoKlare left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laeubi Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laeubi Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laeubi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HeikoKlare commented Sep 4, 2025

Uh oh!

laeubi commented Sep 4, 2025

Uh oh!

laeubi commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

amartya4256 commented Aug 5, 2025 •

edited

Loading

github-actions bot commented Aug 5, 2025 •

edited

Loading

laeubi Sep 4, 2025 •

edited

Loading

laeubi Sep 4, 2025 •

edited

Loading

laeubi left a comment •

edited

Loading

laeubi commented Sep 4, 2025 •

edited

Loading