Three.js: AudioLoader и LoadingManager onLoad Race

Созданный на 2 февр. 2017  ·  3Комментарии  ·  Источник: mrdoob/three.js

Описание проблемы

AudioLoader вызывает scope.manager.itemEnd (через загрузчик файлов) после загрузки буфера, но свой собственный onLoad после его декодирования. Поскольку декодирование буфера является асинхронным (или, по крайней мере, имеет обратный вызов), вы можете попасть в состояние гонки, если аудио-загрузчик является последним загрузчиком в очереди диспетчера загрузки, когда диспетчер думает, что все его элементы завершены, но отдельные загрузчики не закончил разбор. Мы заметили это в нашей ситуации с предварительной загрузкой, и нам пришлось реализовать нашу собственную очередь загрузки, которая использовала для каждого элемента onLoad для отметки полных элементов.

К сожалению, глядя на исходный код FileLoader / AudioLoader, я не уверен, как это исправить, и не вызывает ли это беспокойства; возможно, самое простое решение - просто уточнить в документах, что LoadingManager#onLoad указывает только на то, что сетевой запрос завершен, и не указывает на то, что данные были проанализированы.

Версия Three.js
  • [x] r84
Браузер
  • [x] Все они
Операционные системы
  • [x] Все они
Bug Loaders

Самый полезный комментарий

Хм, так что, я полагаю, AudioLoader не должен передавать менеджера FileLoader и вызывать функции самостоятельно?

Все 3 Комментарий

Хм, так что, я полагаю, AudioLoader не должен передавать менеджера FileLoader и вызывать функции самостоятельно?

Это определенно исправит это для настраиваемого диспетчера загрузки. Диспетчер загрузки по умолчанию все равно игнорирует обратный вызов декодирования, но сколько людей используют диспетчер загрузки по умолчанию в этом контексте?

У меня была такая же проблема. На данный момент невозможно безопасно воспроизвести аудиофайл после срабатывания обратного вызова менеджеров onLoad .

Была ли эта страница полезной?
0 / 5 - 0 рейтинги