search

jimmejardine / qiqqa-open-source

The open-sourced version of the award-winning Qiqqa research management tool for Windows
GNU General Public License v3.0
366 stars 60 forks source link

Qiqqa crashes on ctrl+mousewheel PDF resize zoom #312

Open SimonDedman opened 3 years ago

SimonDedman commented 3 years ago

Hey bud, just had this a few times today, semi-recent build (83.0.7656.6401)

Logs attached; reckon I'll go back to a safe version for a bit while I'm submitting this paper.

Cheers!

2021-03-30_Qiqqa_Crash_On_Mousewheel_Resize.txt

SimonDedman commented 3 years ago

Also got this (attached) after installing the last safe prerelease and opening. Oddly it looked like it crashed, but it didn't.

2021-03-30_Qiqqa_Crash_On_Open.txt

GerHobbelt commented 3 years ago

Quick answer about these UI crashes in the v83 series: I am slowly going through the code locating all the spots where (PDF/search/metadata processing) work is being in the UI thread, which would thus block the UI thread until done. All that stuff is deferred to background threads, thus unblocking the UI thread.

However, this is not a software change that's simple, as all this "any work that can be done by another CPU shall be done by another CPU so this one can keep its attention on UI updates / display repaints" means the run-time flow is suddenly completely different at such a spot in the code: the "work" is never run immediately and the old code expected the result to be ready when it continued to update the UI in the next couple of code lines. Waiting for the answer is a no-go as that would block thee UI thread again, so these code spots change significantly as now the UI code has to behave in another way: "once that stuff is ready, it can call me and I'll see about that repaint/UI-update then".

Mistakes are easily made and what you (and others) are observing are my mistakes while "refactoring" this part of Qiqqa code, one chunk at a time. (Technically, most of the crash reports happen because I misplace a bit of logic that turns out to require direct access to the UI thread for proper operations. Crazy stuff like rendering a page as an image (which is a bitmap and thus that costly process can be nicely relegated to another "background" CPU), then transfering the image bitmap result to the UI thread so it can place it in the UI display properly, only to have a crash from .NET because I forgot to "Freeze" the bitmap (WTF?) before passing the image to the UI thread for display -- which is one of headaches surrounding this sort of work.

The goal is to get the Qiqqa UI to respond a bit smoother (and faster) and most of the crashes one will experience with the v83 test releases are related to this "UI refactoring" work -- which is itself a preliminary for bigger UI changes I want to apply later on, including a move to something similar to an electron-like base for the UI (Qiqqa uses WPF which is non-portable and a horror as far as I am concerned 😉 😞)