qView
qView copied to clipboard
jurplel
Smoothness problem in qView 4.0
Reported on Discord: https://cdn.discordapp.com/attachments/560288287638421515/874680391091519589/1-3.mp4 https://cdn.discordapp.com/attachments/560288287638421515/874680730427465748/1-4.mp4
https://discord.com/channels/137280207202680832/560288287638421515/874689253408387162
Hm... it seems the problem still persists.
qView 3.0: https://drive.google.com/file/d/1NOb9bwyMB23VF1qSY2mDnkU7P_28dz7r/view?usp=sharing qView 4.0: https://drive.google.com/file/d/1Zxc2btCvUfkpbMGjLjNEX13xtx083llt/view?usp=sharing qView 5.0: https://drive.google.com/file/d/17tzqW-p4kOrjBbmO-x51ZGLFjGC_oqMQ/view?usp=sharing
You can see that with qView 3.0 the window frame resizes and the image changes (almost) instantly, creating a butter smooth transition from one image to the next. With newer versions, however, the frame of the previous image still "lingers" on the next for a moment, making the transition less smooth. This seems to happen only when the window frame has to resize, though.
I think it might have something to do with image caching and preloading:
- Even with qView 3.0, when I go to a next image that I haven't opened, I can occasionally see the afterimage. But if I go back to the previous and go forward again, there is no afterimage (the next image is already cached?).
- With qView 4.0 and 5.0, even after I go back to the previous (and then go forward), the frame still lingers (it's like the image is not cached, yet - like opening a image that hasn't been opened?).
One more problem is that 5.0 seems a bit slower than 4.0 in loading images (try browsing quickly by pressing Right Arrow key continuously)...
Replicated on Windows 10 with qView 5: https://user-images.githubusercontent.com/31080003/149659625-c5d647c9-d315-4bb6-90b8-42ac92379e7c.mp4
The transitional frame introduced with version 4:
Transition to smaller image:
Transition to larger image:
@jurplel I believe this is "fixed" or at least greatly improved in the nightly builds. I can reproduce this in 5.0 but not in master. After working on the setWindowSize code recently I have a theory as to what was happening. No, it wasn't my changes there that improved things. But I was playing around with some sleep calls in there and noticed in Windows, when the window is programmatically resized, Windows immediately applies some of the changes visually (it draws the larger window frame with whatever buffered content it already had) and the rest is handled on the next repaint. If the next repaint happens very quickly this isn't noticeable. The problem is more so when something blocks the UI thread and prevents a quick repaint. My theory is that in 5.0 during rapid image switching, the initial updateFolderInfo info call that happens in QVGraphicsView::goToFile was causing this visible delay. I know that code runs before the window size change is requested and the paint should happen after, but I'm guessing during rapid image switching there are key press events queued up, and the event loop was processing one of the arrow key events before it could get to the repaint request.
