Mutex adapter plus other platform specific things #551
Conversation
There was a problem hiding this comment.
All looks good in principle.
My main concern is regarding the drawing mutex and that testing this branch shows to me absolutely no improvement in drawing corruption when testing with a deoptimised build with Tardline.
In comparison testing PR #542 in the same configuration shows no drawing corruption at all.
So I'd want us to merge #542 first and then be very careful with merge conflict resolution on merging this PR afterwards that we don't accidentally lose the fixes from #542.
| @@ -518,7 +519,9 @@ bool AppWindow::onEvent(GUIEvent &event) { | |||
| unsigned short v = 1 << event.GetValue(); | |||
|
|
|||
| MixerService *sm = MixerService::GetInstance(); | |||
| sm->Lock(); | |||
| // TODO(democloid): this causes a deadlock, verify original intent | |||
There was a problem hiding this comment.
my concern here is if the mutex was not actually being enabled (by mistake) but things actually work fine then it really shouldnt be here if it causes a deadlock and we should just remove it.
|
@democloid also need to be careful with merging this after #544 and #545 as this PR is stacked on those and currently includes those commits too. |
|
Macro instrument was still being instantiated using almost 20kb memory. |
Changes:
partially fixes #547