On Thu, Jan 7, 2016 at 9:47 PM, Torsten Paul <[email protected]> wrote:
> That basically sums up the reports so far. On my system I can > reproduce the issue with debug builds, but not with release builds. right - i have a possible explanation for that. if there are two threads now in qt5, one handling mouse-events and the other handling draw-events, if the draw events are *too slow*, then the mouse events get stuffed into the system, queue up and flood the application with redraws. sooo... a debug build would, on *your* system, be slower.... thus the redraws would take longer... thus you would see the problem. but, when you do a release build, it's much much quicker... problem goes away. the reason why i'm seeing this using the models that i'm working with even on release builds is because the models are so fricking complex that i'm looking at SECONDS per frame. yes, really SECONDS to do a single frame, and yes that's genuinely hardware OpenGL not software opengl. to develop the applications i'm doing, i have to code in some special "comment out sections of the model" booleans, so that i can at least get down to a manageable 2 fps (yes, really - *two* frames per second is the compromise i have to work with). so if you have a really really fast desktop system with a high-end NVidia or Radeon graphics with 768Mb or 1gb of RAM and/or a not-so-complex model where the refresh rate is a hundred frames per second, you are pretty much guaranteed *never* to see this problem: the rate at which mouse-events are generated will never, ever stack up to overwhelm such monstrously-fast systems (or such simple models). does that make sense, and fit with the observed incidents seen so far? the solution is to have a boolean or a semaphore around the redraw and the mouse-event logic. on redraw completion, you free the semaphore. just before redraw, you set it. when there's a mouse-event, you don't immediately call "redraw", you check to see if one's in progress (because the flag will be set), instead you set a "redraw is needed" flag. after the redraw completes, you check that "another redraw is needed" flag. if it is, you clear it and... do another redraw. you would, obviously, still need to adjust the positions (rotation) of what's being rotated on each mouse-event. on each mouse-event you would still accumulate the amount of "rotation" (or movement).... you just wouldn't actually do the "draw" because the computer is still busy doing one. as it's extremely likely that qt5 uses separate threads, you might need mutex's instead (round the various flag-setting and clearing) but you get the general idea. not knowing if it's true or not, but if qt4 is a single-threaded design, the reason the problem wouldn't occur would be because the mouse-events would stack up *externally* (in X11) and, in between redraws, i assume that qt4 (or X11) amalgamates multiple mouse-moves into a single mouse-move.... something like that. GUI design is harder than people realise! :) l.
