G4P: GTextField slow input

izumitelj

Hello! I'm having some performance issues with GTextField while using larger font size. While entering text in GTextField that goes past the edge of the field, the input dramatically slows down.

I'm experiencing this on Windows 7 64, Processing 3.1.1 and G4P 4.0.4. Do others experience this as well?

If it is general issue, I have few more observations. Curiously the field is fast when deleting characters with backspace. ControlP5 is also fast, but it doesn't have other features like copy/pasting.

Thank you!

import g4p_controls.*;
import java.awt.Font;

GTextField txf1;
int fontSize = 80;

void setup() { 
  size(800, 600);

  txf1 = new GTextField(this, 100, 250, 600, 100);
  txf1.setFont(new Font("Arial", Font.PLAIN, fontSize));
}

void draw() {
  background(125);
}

quark

I assume you have tried smaller font sizes? There should be no difference in performance if there is more text than fits the text field but I won't be able to test it for several weeks ago I suggest you create a ticket on Sourceforge.

izumitelj

With smaller sizes it's a lot less noticeable, but you can still see it if you type really fast or if you paste small chunk of text.

The slowness is ONLY noticeable when there is more text than fits the text field.

It seems like it has something to with how text/graphic is rendered, but thing that is confusing is that erasing characters with backspace is very fast and responsive. I've opened the ticket.

@quark do you think I should post discoveries like this here, or it's better to do it directly on Sourceforge?

Thanks

quark

I would suggest that you post in this forum first in case it is a known issue or a solution is already known. I asked you to raise a ticket because I can't do anything about I it it for a couple of weeks and this post would be forgotten long before then.

quark

I have tried to reproduce the problem without success. This movie shows what I got with rapid key presses and pasting text blocks

izumitelj

Hi @quark! You exactly reproduces the problem.

But the problem is not appearance of smoothness but slowness or extreme time lag between user action and computer feedback. In your video it is clear that after you finished typing on the keyboard the text continued to type solo for next 8 seconds! That means that while the user is typing they don't actually see what they are typing, and they have to wait a lot before interface updates, and before they can make next action (or correct typing error).

This unresponsiveness is big user experience issue that becomes evident if you try to use it in real context where users actually need to do something. (I did it for one public installation).

Best regards

quark

I understand the issue now and will investigate the problem. Thanks.

izumitelj

Sounds great! I'll stay tuned if there is need for some testing. Thanks!

quark

OK so I have identified the cause of your issue and it is not related to performance or how the characters are rendered.

The first thing to understand is that scrolling the visible text is ONLY done if needed to keep the text insertion pointer (TIP) inside the visible area of the textfield. That is why deleting characters is to be unaffected.

So now imagine we have been typing and the TIP is at the far right of the control. If we type the letter "m" then it would force the TIP outside the RHS of the visible area. G4P will then scroll the text left until the TIP is within the visible area and currently it does this 4 pixels a frame which explains why this issue is more noticeable with larger fonts. Even when the TIP is outside the visible area the control will still accept characters from the keyboard which explains why it would appear more noticeable with fast typists and when chunks of text are pasted in.

The reason I took this approach was that the smooth scrolling is more visually aesthetic.

I have 2 options

1) Move the text so that the TIP is always visible (i.e. every frame). It means that scrolling would be the character width or the width of the pasted text.

2) The scroll per frame distance would increase as the font size increases (and visa versa) i.e. dependent of the font size. It would still cause a significant scrolling delay when pasting in large text chunks.

Do you use the paste text option much?

I need sometime to weigh the pros and cons of each approach and do some more experimentation but I am interested in hearing any comments you might make before I reach a final decision.

quark

After careful thought I prefer approach (2) but it would not help with very fast typing speeds so I have decided to try a third option -

3) the amount of scrolling depends on the font size AND the user's typing speed (characters per second).

This movie shows the modified library in action.

If this is looking good then I will take you up on the offer to test it.

izumitelj

Hi there! Sorry for not reacting immediately, I've somehow missed notification about the post you added two days ago.

This (3) approach and result looks perfect. I'm ready to test it :)

quark

I have sent a PM to you with my email address. Send an email to me and I will send the library jar and instructions how to install it.

izumitelj

Hi @quark!

I've made some tests with updated library. It's a big difference in responsiveness and I don't see any need to improve it further :)

I've discovered one bug though. When you enter larger amount of text (go beyond visible area, let's say 100-200 chars), and you press Home or End button to move TIP to the beginning or the end of text, I get the error:

map(NaN, 0.1, 20, 1, NaN) called, which returns NaN (not a number)

...and the TIP indicator than disappears.

I've also tested this with the unmodified library. The error doesn't happen then, which means bug is probably introduced with this fix.

Let me know if I can help testing further.

Best regards

quark

Thanks I will try and reproduce that NaN error before the next release.

quark

TYou were right the NaN bug you found was introduced by the bug fixes and has in turn been fixed for the new release V4.0.5

I have just released G4P V4.0.5 which can be downloaded from Sourceforge. It will probably be about 24 hours before this new release will be available through the PDE.

izumitelj

Thats great! Thanks :)) (again I missed your reply here. Sometimes I get notfications, but sometimes not)

quark

I didn't post here until after I closed the issue on Sourceforge which would explain why you didn't see this before notification by Sourceforge