Opened 11 years ago

Closed 11 years ago

#9841 closed bug (fixed)

Debugger: Avoid flickering when stepping

Reported by: stippi Owned by: anevilyak
Priority: normal Milestone: R1
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (3)

sourceview_flicker.patch (2.4 KB ) - added by anevilyak 11 years ago.
reduce_flicker_v2.patch (6.2 KB ) - added by anevilyak 11 years ago.
Reduces source and stack trace view flicker
markerview.patch (1.7 KB ) - added by anevilyak 11 years ago.
Fix flicker in breakpoint marker view

Download all attachments as: .zip

Change History (16)

comment:1 by anevilyak, 11 years ago

patch: 01

comment:2 by anevilyak, 11 years ago

Status: newin-progress

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.

by anevilyak, 11 years ago

Attachment: sourceview_flicker.patch added

comment:3 by bonefish, 11 years ago

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.

comment:4 by anevilyak, 11 years ago

Will try that, thanks for the suggestion.

by anevilyak, 11 years ago

Attachment: reduce_flicker_v2.patch added

Reduces source and stack trace view flicker

comment:5 by anevilyak, 11 years ago

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.

comment:6 by anevilyak, 11 years ago

Resolution: fixed
Status: in-progressclosed

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

comment:7 by stippi, 11 years ago

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!

in reply to:  7 comment:8 by anevilyak, 11 years ago

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.

by anevilyak, 11 years ago

Attachment: markerview.patch added

Fix flicker in breakpoint marker view

comment:9 by anevilyak, 11 years ago

Resolution: fixed
Status: closedreopened

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

Version 0, edited 11 years ago by anevilyak (next)

comment:10 by stippi, 11 years ago

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.

in reply to:  10 comment:11 by anevilyak, 11 years ago

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.

Last edited 11 years ago by anevilyak (previous) (diff)

in reply to:  3 comment:12 by anevilyak, 11 years ago

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?

comment:13 by anevilyak, 11 years ago

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.