poedit
poedit copied to clipboard
vslavik
2.0’s list control is slow (deleting text, scrolling)
Poedit 2.0beta3 Windows 10
To reproduce:
- Open a .po file that has at least 400 messages
- Select an entry that is not too short, e.g. entry 5 "cannot create a temporary directory"
- Place the text cursor in the translation input field, press
Endand then holdDel
Deleting the characters is slow. I have set the repeat rate to the highest possible value (about 30 chars/sec), but when deleting text in Poedit, only 15 chars/sec are actually deleted.
I tried to disable the spellchecker, which had no noticeable effect. I tried with a very small .po file (only 2 messages), and there it went smoothly. Therefore I think it could be related to repainting the screen. Deleting text in the Ctrl+M window is fast, as usual. The slowness seems to be only in the translation field.
And I take it this was not the case in 1.8?
Two potentially related things changed in 2.0:
- The list control is different.
- (Much) more syntax highlighting in the text control itself is going on.
If the list size matters, this would indicate 1. as the cause. Does it matter how many entries are in the PO file or just how many of them are shown on screen? If it's the latter, making the list small by dragging the separator between the text area and the list would speed it up.
1.8 is twice as fast as 2.0.
I think it is related to the number of entries shown in the list. When I try it in a minimal file (1 message), it is about 30% faster than with a large file. Still, 1.8 is so fast that I can see each character being deleted individually. With 2.0, sometimes two characters disappear from the screen at the same time, which makes the UI appear slow.
It also depends on how much text there is in the translation window. When I repeatedly paste a whole sentence into the translation window, pasting becomes noticeably slow. (I know that this does not matter in practice, since most messages are quite short, but it helps identifying the root cause.)
The spell checker is a big performance problem. To reproduce:
- Open a small .po file in Poedit 2.0beta3
- Enable spell checking
- Copy some paragraph into the clipboard
- Focus the translation field
- Press and hold Ctrl+V for about 10 seconds. Then release them
When spell checking is enabled, pasting continues long after Ctrl+V has been released (several minutes) and Poedit becomes unresponsive. Without spell checking, it is fast.
The spell checker is a big performance problem.
Err… Spellchecker is certainly expensive, but it's only a "performance problem", let alone a "big" one, if it impacts normal sane use, which I think you'll agree this example doesn't (unlike holding Del and that being slower than it should be). In any case, spellchecker is native to the RICHEDIT control and I can't affect it much; it's also unchanged from 1.8.
Another I think related report from @przemo20 is that scrolling lags (see https://youtu.be/YjkNZ3N5baM) — I think it’s all the same underlying performance problem with wxDataViewCtrl, so adding it here.
Can you share some information about your hardware, w.r.t. CPU performance and screen resolution? I can’t see it, or any lagging when scrolling with mouse, here (Control Panel, Keyboard, Repeat Rate set to the right-most Fast position). (I can see some degradation in unoptimized debug builds, but that one is generally very slow in everything…)
Notes to self:
- [x] Apparently, wxDVC resorts (which is fortunately noop in Poedit’s case) and repaints the entire window every time any change is made. This is a major part of the issue and will be relatively hard to fix in wx :( It’s also something proportional to screen size rather than PO file’s size.
- [x] Every time, columns widths are recalculated. This is something that can be addressed in Poedit itself. This is proportional to PO file size.
I'm also experiencing the same issue, but the uploaded test build link has expired. I'd like to get a new one to test.
@ItielMaN Sorry, I no longer remember what that was about, and can't find any related work-in-progress in my local tree. So presumably whatever this was was already merged or discarded as useless.
When I scroll using the mouse wheel, the part with the exclamation marks scrolls noticeably slower than the part without the exclamation marks. Do you have an explanation for that? Painting a simple 24×24 icon per row shouldn't be that expensive.
The color of the text (orange or black) doesn't seem to have any effect on the painting speed though.
Can you configure the list to not paint itself at every mouse wheel event as if by SendMessage(WM_PAINT), but only call PostMessage instead? This would already help when scrolling using a mouse wheel. Does wxWindows merge multiple paint events into one, or would you have to do this yourself?
Do you have an explanation for that?
No, but it's a useful observation, thanks! (Would be useful to have that specific file in its specific state shown above.)
Painting a simple 24×24 icon per row shouldn't be that expensive.
Let me put it this way: such assumptions (including the followup ups) are easy to make from a distance, but look at the control's code. It's huge, complicated, and somewhat fragile :(
Painting a simple 24×24 icon per row shouldn't be that expensive.
Let me put it this way: such assumptions (including the followup ups) are easy to make from a distance, but look at the control's code. It's huge, complicated, and somewhat fragile :(
I know. Luckily I'm at a distance most times. And I know from my current day job how difficult it can be to step through UI code. 6000 lines is a nice bunch of code, and it almost looks like Java Swing. Still, it's too much code to grasp in a single evening.
Bitmap rendering is indeed expensive in wxDVC if the bitmaps have alpha channel: around 40% of time is spent in it here! It's due to the need to do repeated conversions between formats deep in wx code, but it's something that can be worked around fortunately.
Scrolling is trickier: wx insists on doing it one line by one line, repeatedly, with an optimization to draw only the newly appearing lines. This can actually be slower than fully repainting the entire window… and is deep in wx's internal logic.