Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Race condition for isVisible (and possibly more checks) #327

Open
BrendaH opened this issue Dec 7, 2020 · 1 comment
Open

Race condition for isVisible (and possibly more checks) #327

BrendaH opened this issue Dec 7, 2020 · 1 comment

Comments

@BrendaH
Copy link

BrendaH commented Dec 7, 2020

When looping over sources to set their visibility (item.setVisible(self.visible)) only the last source was actually updated with the given visibility. It looks like there's a race condition where an item is put into a 'slot' and then the visibility is adjusted. However, when another item has to do the same thing at (nearly) the same time, it might happen that the 'slot' is filled with this newer item before the visibility change is applied. Resulting in it only working on the last item.

This might be related to the comment about async attaching here: #297 (comment)

I circumvented this by awaiting just about everything that is going to Xsplit/xjs, but this was quite unexpected behaviour.

@SML-MeSo
Copy link
Collaborator

Shoot... Did a little check and indeed encountered the above-mentioned issue using a simple test

xjs.Scene.getActiveScene().then(scene => {
  myScene = scene;
  return myScene.getItems();
}).then(items => {
  myItems = items

  myItems.forEach(item => {
    item.setVisible(false)
  })
});
// only the last two items are hidden

Looked into it further by getting the properties instead and it now yielded the correct results (two true and two false values). While the second test did support my answer to the mentioned comment, it also showed that there's an inconsistency on the synch-ness of the calls to attach and setting and getting properties. Will check this further on core but as of now, yeah, we might need to use await to ensure that the proper items and their method calls are in synch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants