Lemur textfield invisible?


#21

One is 3.2.1 in sdk, and the other is master with netbeans 8.

Thats just with default font. I created a arial and it does it at 13. Console does it every other character just about.


#22

Sorry I haven’t been able to look into this myself yet because I was rebuilding my game development machine. Slowly getting it back to dev-capable.


#23

The issue seems to be related to the cursor size. The width of the cursor bar is set to be font.getLineHeight()/16f. So I guess values < 0.75 start to have problems in some positions. Like somewhere in the OpenGL/JME stack, a non-integer x position combined with a <0.75 quad width = nothing drawn at all.

I tested this by artificially increasing the width to just plain 5… and then the cursor is always visible.

(And before anyone suggests it, Math.max(1, height/16) is also not a solution because the text could be in 3D space where 1 unit is a meter… and test height is probably super-small in that case.)

Unfortunately, unless I can think of why the quad is getting completely swallowed (or if someone else knows), there is no real solution to this problem. I mean, I can add additional heuristics to the cursor width calculation and even make it settable (and I will do both) but in the end there will always be some font size that will confound this and require the tedious need to set the cursor width. (And anyway, the ability to set the cursor width is probably a good idea in the end.)

I’m going to dig a little deeper into JME to see if I can find the real issue.


#24

So it’s nothing JME is doing… something down in OpenGL decides not to render anything at certain x positions when the width < 0.75 or so. It wasn’t even logical cases to me. Like, the quad technically still spans pixel boundaries in the cases being swallowed.

Anyway, I’ve added code that should fix this behavior and make it overiddable in any case:


#25

I will try it shortly, thank you for tracking this down so quickly.


#26

Reading this from my job computer (so only internet).

The changes made look OK, but is

necessary? In my understanding it must move the cursor closer to the last letter in the text as before.

cursor.setLocalTranslation(x, y, 0.01f); before 
cursor.setLocalTranslation(x - getCursorWidth() * 0.5f, y, 0.01f); now

Maybe I am just a nagger esp. as I have not tested this, but as
x is depending on linewidth and now we deduct a multiple of lineheight (or any set value) from it. Might there be a chance that this leads to a cursor that is moved to far left?


#27

It’s centering the cursor over the cursor position.

To me, this looks less strange than clobbering the whole next letter if you have a wide cursor… and will be more appropriate if/when you are allowed to give the cursor a texture.

Put another way, by default cursor width will be 1/16th of the line height… and will be offset 1/32nd.

So even if your font were 72 units high, the cursor width is 4.5 units and will be offset by -2.25 units. But it’s also likely that the spacing between letters is close to 6 units.

For thin/default cursors, this is a difference like:

For overly thick cursors, this is a difference like:

It’s not clear to me for sure which “ugly” is better but the second way would work better for cursor textures (for example, the standard sort of cursor bar).