Scene2D UI Table widget click area is offset from drawn widget

Issue details

Create a stage with a table with a checkbox. Clicking the top of the checkbox does not register (checkbox state does not change). Clicking approximately lower 2/3 of the checkbox registers (checkbox state changes). Clicking slightly below the checkbox registers (checkbox state changes). The issue persists with other widgets but is less noticeable for bigger widgets like buttons. Widgets work as expected if you do not table.setFillParent(true); or otherwise set table dimensions. Widgets also work as expected when used without a table.

Reproduction steps/code

Create a stage with a table with a checkbox. Example uses default skin from https://github.com/czyzby/gdx-skins

package com.mygdx.game.tablewidgettest;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.scenes.scene2d.Stage;
import com.badlogic.gdx.scenes.scene2d.ui.CheckBox;
import com.badlogic.gdx.scenes.scene2d.ui.Skin;
import com.badlogic.gdx.scenes.scene2d.ui.Table;
import com.badlogic.gdx.utils.viewport.ScreenViewport;

public class TableWidgetTest extends ApplicationAdapter {
	Skin skin;

	Stage stage;

	Table table;
	CheckBox checkBox;
	
	@Override
	public void create () {
		skin = new Skin(Gdx.files.internal("skin/default/uiskin.json"));

		stage = new Stage(new ScreenViewport());

		table = new Table();
		table.setFillParent(true);

		checkBox = new CheckBox("Test checkbox", skin);
		table.add(checkBox);

		stage.addActor(table);

		Gdx.input.setInputProcessor(stage);
	}

	@Override
	public void render () {
		Gdx.gl.glClearColor(0, 0, 0, 1);
		Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
		stage.act();
		stage.draw();
	}

	@Override
	public void resize(int width, int height) {
		stage.getViewport().update(width, height, true);
	}

	@Override
	public void dispose () {
		stage.dispose();
		skin.dispose();
	}
}

Version of LibGDX and/or relevant dependencies

1.9.8 1.9.9-SNAPSHOT (as of 04/14/2018)

Stacktrace

N / A

Please select the affected platforms

• Android
• iOS (robovm)
• iOS (MOE)
• HTML/GWT
• Windows
• Linux
• MacOS

[tommyettinger]

I’m only aware of high-DPI code being usable on LWJGL3, since LWJGL2 was written when screen DPI was rarely as high as it is now. LWJGL3 also handles multi-monitor setups instead of only using one monitor. It should be rather easy to change the backend, if you want to try LWJGL3, but I’m not sure if the process is documented here on the wiki. You’d change a few Gradle dependencies from lwjgl to lwjgl3, and then the DesktopLauncher class in the desktop module needs to be slightly different. Nothing in the core module should need to change.

Steps to change, as best as I can remember: Where you see compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion" , change it to compile "com.badlogicgames.gdx:gdx-backend-lwjgl3:$gdxVersion" . This line near it stays the same, compile "com.badlogicgames.gdx:gdx-platform:$gdxVersion:natives-desktop" . There’s a commit in a repo I work on that has a pretty good example of what the changes would look like for going from LWJGL2’s configuration to LWJGL3; here’s the highlighted file, with ‘-’ to remove LWJGL2 lines and ‘+’ to add LWJGL3 lines. You can see the code is similar, mostly just changing LWJGL to LWJGL3 and going from setting fields to calling setter methods, but there’s also some WIP comments there and I hope they don’t make it hard to read. The classes to import also change.

It’s possible this is a bug in checkbox code for scene2d.ui, it’s possible that it might be resolved fully by using LWJGL3, it’s possible that it’s an operating system bug related to the input not being given correctly to applications, and it’s possible that it’s not something that could be fixed, but could instead be worked around. I’m hoping LWJGL3 being more aware of HDPI screens will mean it gets more precise input and so can respond correctly to clicks. There’s a class in LibGDX that I haven’t needed yet called HdpiUtils, and it may have a solution here (maybe it needs to be added to scene2d.ui code, not sure).

Personally, I’m hoping LibGDX makes LWJGL3 the default backend for desktop soon, since it just generally seems better and is actually receiving updates. There may be outstanding bugs, but I don’t think there are very many of them. I think the Java 9 issues it had briefly during early access of OpenJDK 9 were resolved, and there were also some early hiccups when LWJGL3 was first released a while ago. I think it’s been very stable since those were fixed. It’s probably hard for some devs to test multi-monitor setups for their games, but from what I’ve seen supporting multiple monitors with fullscreen and the like has been a common request from players, and that’s a good reason to use LWJGL3.

[tommyettinger]

I tried this example on libGDX 1.9.6 and 1.9.8, also on Windows (here, Windows 7 64-bit), with LWJGL2 and LWJGL3, but can’t reproduce as-is. However, I’ve had a similar issue where the mouse-responsive area of an input component was offset from the actual screen area, though I don’t have the code easily available so I can’t be sure if it was scene2d-related or related to my mouse handling. @IronRex , could this be an issue with the monitor resolution being seen incorrectly by scene2d/your application? LWJGL2 does not handle high-DPI monitors very well. My laptop screen has 96 pixels per inch and Windows is configured to apply no scaling, if it helps for comparison.