Holding backspace in the translation field only slowly updates the text field

[rillig]

When I have a text of about 30 words in the translation text area and I press Backspace, the characters are deleted and the screen is updated accordingly.

The strange thing is that the list of messages is updated first, and only after painting the list has finished will the text area be painted. This leads to the strange situation that I delete the text blindly, and to see how much I have already deleted, I have to release the Backspace key and wait for the painting to finish, which can take up to 600 ms, even on an Intel Core i7, which is really fast compared to my old AMD processor.

This makes Poedit feel slow and unresponsive.

Updating the text area should have higher priority than updating the list of messages.

In this screenshot, the list already shows that the text ariable has been deleted, while the text area (wrongly) shows that the text is still there.

[vslavik]

painting to finish, which can take up to 600 ms, even on an Intel Core i7, ... This makes Poedit feel slow and unresponsive.

No kidding. This is abnormally slow. I don't think I've observed something as insane as that… even running in slow-ish VM.

Are you certain you're using 2.2.1 and not 2.2 (inferring from another issue)? 2.2.1 includes a9d1b0c22d1fba81fca17bf4645d1e14e75e476c that mitigates some issues in this area.

Could you please share your exact CPU model, and ditto for GPU, double-check in task manager that nothing else is crazily using-up CPU at the time, and possibly share the file (although I assume it's the gcc one you mentioned elsewhere)? Another issue has shown Win10 interface, this is I assume latest update of it?

Updating the text area should have higher priority than updating the list of messages.

My view is that both should be unnoticeable. The issue here is not painting as such, but typing notification, which is sent by win32 as you type (and apparently, at least in the richedit and win versions you have) before painting the control… and there's some CPU-intensive work done in response to that that should be there (after a9d1b0c22d1fba81fca17bf4645d1e14e75e476c).

I think this may particularly noticeable on the über-huge gcc files (they make a great testcase that way) and smaller files may be OK. If so, that would prove that the list control is still doing some resizing calculations in response to text change, instead of just updating and repainting the single affected row.

[rillig]

Are you certain you're using 2.2.1 and not 2.2 (inferring from another issue)? 2.2.1 includes a9d1b0c that mitigates some issues in this area.

Yes, I'm certain. The About dialog says 2.2.1 (5661).

Could you please share your exact CPU model, and ditto for GPU, double-check in task manager that nothing else is crazily using-up CPU at the time, and possibly share the file (although I assume it's the gcc one you mentioned elsewhere)? Another issue has shown Win10 interface, this is I assume latest update of it?

I have 8 of these, as reported by Cygwin's /proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 142
model name  : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
stepping    : 10
cpu MHz     : 1992.000
cache size  : 8192 KB
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt aes xsave osxsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

My graphic cards are:

• an Intel(R) UHD Graphics 620, PCI\VEN_8086&DEV_5917&SUBSYS_121E1025&REV_07\3&11583659&0&10
• an NVIDIA GeForce MX150, PCI\VEN_10DE&DEV_1D10&SUBSYS_121F1025&REV_A1\4&2C193CA8&0&00E0

A file to reproduce this is gcc-8.1.de.po. Open it and save it to get the warnings. To get even more warnings, run:

sed -i 's,^\(msgstr "..*\)"$,\1.",' gcc-8.de.po

I think this may particularly noticeable on the über-huge gcc files (they make a great testcase that way) and smaller files may be OK. If so, that would prove that the list control is still doing some resizing calculations in response to text change, instead of just updating and repainting the single affected row.

Could you provide me with a debug build that sets random foreground and background colors on each paint event? Or maybe like this:

global uint8_t foreground = 0
global uint8_t background = 128
on each paint:
    foreground += 40
    background += 40

That should make all paint events nicely visible. For resizing, you could use one of the RGB channels, to make both observable at the same time.

[vslavik]

Do you have the ID column hidden? If yes, does enabling it (View → Show string ID) make a difference?

[rillig]

Yes, I did have the ID column hidden. No, it did not make a noticeable difference.

When I'm scrolling really fast, my mouse generates about 100 events per second. Could it be that wx cannot handle these in a timely fashion? Here's a picture of the mouse events. Each pixel represents a measurement period from 200ms. The horizontal line in the middle means there is no mouse scrolling at that time. The blue pixels are the scroll amount, and the red pixels are the number of scroll events.

In the left part of the image, I scrolled down. First slowly and then, by letting the mouse wheel turn freely, very fast (the blue line coming from the bottom). The number of scrolling events is limited to about 27 each 200ms. The scrolling amount may still be larger. Now if wx generates a paint event for each of these mouse events, that could already explain why the event queue fills up.

[vslavik]

Could it be that wx cannot handle these in a timely fashion?

Yes (in a way; it lags behind input in scrolling, processing all individual adjustments one by one), see the other issue here. But this one is about holding backspace…

If you don't see a difference while holding backspace, that's concerning. Toggling the ID column definitely does have an impact, it eliminates the most expensive portion of the hot path completely, so if it doesn't make a difference, there must be other issues too :(

[vslavik]

Ah, I realize the other issue, which is closely related, wasn't link here, so here I go: #340.

[vslavik]

How's this build?

[rillig]

How's this build?

It shows the same behavior. It may be 20% faster but still continues scrolling more than 0.5 seconds after I stop the mouse wheel.

There's something else which might be closely related or even lead to the root cause:

Poedit fast mouse wheel scrolling.zip

At 00:00 I release the mouse wheel so that it can spin freely. At 00:03 I push the mouse wheel as hard as possible to scroll down. Until the end of the video, I don't touch the mouse at all. The funny behavior is that Poedit first scrolls down until 00:05, then scrolls up again until 00:07 and then scrolls down again. All this without me touching the mouse. At 00:15 the mouse wheel has stopped to move.

In some cases, the scrolling direction changes multiple times. It also happens in the lower area of the translations list, where the iconless items are and are painted quicker.

Could it be that there is an integer overflow somewhere in the event processing? It looks a bit like it, but I'm not sure how I could prove that assumption right or wrong.

[vslavik]

still continues scrolling more than 0.5 seconds after I stop the mouse wheel.

Again: this issue is not about scrolling. The issue, as you described it, is about holding backspace in translation field. Can you please respond on how this build affects that?

As for mousewheel scrolling continuing after you stop touching it, please compare with Explorer — some about of that is normal, intentional inertia.

where the iconless items are and are painted quicker.

The icons issue (as in #340) is eliminated in that build. If you're still seeing it, it's possible you're not running the new build. Make sure to quit any other instance of Poedit first, otherwise launching Poedit.exe just tells the pre-existing instance to open a file.

Could it be that there is an integer overflow somewhere in the event processing? It looks a bit like it

Frankly seems more likely to be bad input from touching the wheel again. As far as applications are concerned, the mouse was still generating events. That big inertia between reacting (2s between 00:03 and 00:05) would be consistent with accidentally not running the experimental build.

[vslavik]

You can verify the build is correct in Help → About: the build number should be 5698.

[rillig]

I'm sorry I confused this issue with the one about slow scrolling.

Back to topic:

• When I press Backspace at the end of a long text, build 5698 behaves much smoother than build 5661.
• Build 5698 deletes 30 characters per second, which is exactly the repeat rate of my keyboard.
• Build 5661 looks like it would delete only complete words instead of individual characters.

So yes, build 5698 improves the situation a lot.

[vslavik]

In other words, scrolling is still suboptimal even with the fixes, but at least typing works better. Thanks!