Re the issue with not being able to dock Piano and MIDI bars to a tabbed pane: I looked into that some more. It's a non-trivial issue with pros and cons that need consideration. But the short form is this: Currently, keeping many of the bars in tabbed panes may make the UI sluggish. This is especially true of the Step Values bar!
When a bar is docked to a tabbed pane, Windows considers it "visible" even if it's not the active tab, in which case it's not actually visible to the user. In my current implementation, such "visible but inactive" bars receive document updates (affecting performance), though they don't get "painted".
It seems reasonable that hidden bars shouldn't consume any CPU cycles. When a bar gets "shown" my code assumes the bar is "dirty" (meaning it wasn't being updated while it was "hidden"), and updates it. But there's a catch to that work-saving strategy: bars that show real-time events (e.g. the Piano and MIDI event bars) will miss events that occur while they're hidden. This is why when you show the Piano bar, it doesn't display notes that were already in progress by the time you showed the bar; it missed those events.
It's also why I had to disable tabbed docking for Piano and MIDI event bars. Those bars have big impact, because they oblige the sequencer to send a "monitoring" copy of the entire output MIDI sequence to the main thread. If those bars were allowed to tab-dock (or auto-hide), they would drag performance even though they might not be visible to the user. This seemed wrong to me, so I disallowed it.
It's a messy situation with competing design goals. On the one hand, it's nice if bars don't consume resources while they're "hidden". On the other hand, it's annoying that when you show the Piano or MIDI event bars, events that occurred while they were hidden are missing.
No comments:
Post a Comment