Clicking on subs lags a lot the application

[shanksfigarland]

First of all, very nice initiative of coming up with this. It will help a lot of people.

I didn't quite get if it's a hover thing or a click thing, but either way it lags the program A LOT. It doesn't show up properly and when it does it's a blink of a second. I had to keep my cursor on top of it for it to show and took a few seconds which is bothersome.

Suggestion: Hold some key and hover on the word for it to appear. Or simple click on it.

[ripose-jp]

The way searching works now is a hover system, so clicking doesn't have any affect.

Assuming I'm describing the same problem, there seems to be a lot of latency between searching for words written in kana like そうやって and しかない relative to searching something that contains kanji. I think this is because the search algorithm is matching a lot more results in these cases. しかない turns up 175 alone with only jmdict and jmndict, while Yomichan only comes up with about 30.

I'll likely add an option to limit the number of results that show up and set it to something sane by default.

I'll also look into adding an option to only search when a modifier key is pressed for the next release.

[shanksfigarland]

That might work. The way when I hover right now it breaks the application forcing you to close it.

[ripose-jp]

I've made a new release, v0.4.2-alpha that will hopefully alleviate this a little. The default limit for search results is 30 and it adds the ability to use modifier keys instead of hovering.

It seems that EPWING dictionaries like 三省堂　スーパー大辞林 slow down searching much more than something like jmdict, so you might have to lower the limit if searching still doesn't feel fast enough. Interestingly, this is only a problem on Windows and not on Linux, so until I get to the bottom on that, I'm going to leave this issue open.

[ripose-jp]

After some testing I found out the bottle neck for showing results is painting the results on the screen. Due to how Windows handles UI updates, I doubt there is much I can do fix the problem beyond painting less information on the screen.

In response, I've lowered the number of results that show up by default to 10 and added a button to show more search results if desired.

This issue will remain open indefinitely.

[rampaa]

I doubt there is much I can do fix the problem beyond painting less information on the screen

AFAICT this is essentially true but here's the approach I've taken in my app that worked quite well for me, in case it's useful for you too:

There's a thing called UI Virtualization in WPF, which essentially defers the rendering of results until they are displayed. I'm not sure whether there's anything similar to VirtualizingStackPanel in Qt or not, but leveraging UI virtualization improved the lookup speed of my app quite a lot. Before making use of UI virtualization, showing all the results for something like トリコ took over 3 seconds when many dictionaries were loaded. After making use of UI virtualization though, it now takes less than a second even when many dictionaries are loaded. So I thought I might as well mention this in case something similar can be done in Qt as well.

[ripose-jp]

The UI virtualization idea is definitely a winner. Qt has implemented it, but unfortunately only for Quick and not for Widgets. This is unlikely to change since Widgets isn't making them money like Quick is. That said, I could rewrite the search box to use a Quick ListView instead of Widgets ScrollView and reap the benefits. I'll have to look into it more.

Thanks for the tip.