Debugger: Avoid flickering when stepping

[stippi]

It doesn't happen always for some reason, but usually when stepping, there is alot of flickering going on. Most notably the source view itself flickers and the stack trace in the Threads page. The stack trace seems to be emptied and refilled, for the source view, I have no speculation as to what happens to make it flicker. Maybe BWindow::BeginViewTransaction() and EndViewTransaction() may be of help, otherwise I would somehow disable and re-enable graphical updates in those views until everything has settled down again.

[anevilyak]

Please let me know if the attached patch helps for the source view at least. The stack trace does indeed get emptied and refilled, since there's no way of knowing in advance where you'll in fact end up after a given step. That one I'll need to investigate a bit more as far as the drawing side goes though, since that's somewhere down in BColumnListView.

[bonefish]

When the stack trace is set to NULL, how about delaying the operation for a short time (e.g. 0.5 s)? When stepping, in most cases a new stack trace will be set long before the end of the delay. When running or stepping into a syscall that waits, I don't think the small delay will cause any confusion.

Without looking at the source, I guess the implementation should be fairly straight forward. A BMessageRunner could be used for triggering the delay. Since most model objects in Debugger are referenceable anyway, it shouldn't be a problem too keep them a while longer than one would usually do.

[anevilyak]

Will try that, thanks for the suggestion.

[anevilyak]

Reduces source and stack trace view flicker

[anevilyak]

That seems to help indeed. Over here the main thing remaining noticeable between steps is flickering of the top tab view, need to see what's going on there still.

[anevilyak]

Fixes will be available in hrev45802. Let me know if you notice any other instances please.

[stippi]

It's much improved. There is some jerking in the variables view. It looks a bit as if it's either showing different content very quickly, or maybe it's being rebuilt with all entries expanded and then they are quickly collapsed when the state is restored. I can also watch the possible breakpoint dots of the source view quickly disappear and reappear, although the code itself no longer flickers.

Your BTabView change has a regression, BTabViews in other apps open without an initially selected tab. You can test for example with the Appearance preflet.

Thanks for working on this ticket so quickly!

[anevilyak]

Replying to stippi:

It's much improved. There is some jerking in the variables view. It looks a bit as if it's either showing different content very quickly, or maybe it's being rebuilt with all entries expanded and then they are quickly collapsed when the state is restored. I can also watch the possible breakpoint dots of the source view quickly disappear and reappear, although the code itself no longer flickers.

Will see what I can do with the variables list. As far as the breakpoint dots go, that should simply be a matter of applying a similar fix as was done with the textview itself, I wasn't seeing a flicker with that section of it over here though.

Your BTabView change has a regression, BTabViews in other apps open without an initially selected tab. You can test for example with the Appearance preflet.

Thanks for the hint! Fixed in hrev45805. Looks like I may need to also revert the checkbox change we spoke about. Seems quite a few places specifically rely on that max size behavior in order for the checkboxes to automatically left align themselves.

[anevilyak]

Fix flicker in breakpoint marker view

[anevilyak]

Please see if attachment:markerview.patch​ resolves the flickering on your machine.

[stippi]

There is still fallout from your BTabView change... :-) If you run Terminal, open a second tab, then run "exit" in the second tab, you get an empty Terminal window instead of the contents of the first tab. That's at least what I found so far. Unfortunately I forgot to apply your markerview.patch before compiling the new image... will try that next.

[anevilyak]

Replying to stippi:

There is still fallout from your BTabView change... :-) If you run Terminal, open a second tab, then run "exit" in the second tab, you get an empty Terminal window instead of the contents of the first tab.

Thanks, overlooked that, RemoveTab() was manipulating the index directly instead of letting Select() handle adjusting it, which broke when short circuiting. Fixed in hrev45806. From the looks of it, no other places in BTabView's code do this, so that should be the last of it. On a loosely related note, I seem to have stumbled across a Terminal bug/race of some form in the process: occasionally Terminal would close the entire window on cmd+w instead of just the active tab. Haven't found a reliable set of steps to reproduce it yet though.

[anevilyak]

Replying to bonefish:

When the stack trace is set to NULL, how about delaying the operation for a short time (e.g. 0.5 s)? When stepping, in most cases a new stack trace will be set long before the end of the delay. When running or stepping into a syscall that waits, I don't think the small delay will cause any confusion.

After digging into the flickering in the VariablesView, and also noticing the same problem affects the step control buttons, a thought: it might make more sense to actually adapt the above a bit, and have it done at the level of the TeamWindow itself, rather than the stack trace view. That way the state of the buttons won't flicker for a short single step, and also the variables view won't flicker due to having its stack frame cleared (which was also a missing step). The only problem then becomes notifying them when we're in the wait state so they can guard against having items clicked/selected during the delay window, but that should be straightforward enough. Seem like a better plan?

[anevilyak]

Remaining flickering issues (that I could find) should be fixed in hrev45808.