Comments 6
В рамках коммерческого проекта реализовывал через OffscreenCanvas трансляцию с видео камеры и захват экрана, обработку WebCodecs в качество (encode/decode) и все это обернуто в WebWorker. Половина функционала экспериментальная в Хром, но все же работало!
Обычно сразу плохо рендерить на экран - сначала все рендерится в так называемый backbuffer, вопрос - в основном потоке данный канвас доступен чтобы с него можно было скопировать на другой канвас?
Зачем это все? Канвас сам по себе фреймбуфер который будет отрисован только в animation frame вызов в браузере. В webgl вообще есть persistentDrawBuffer хинт чтобы нивелировать инвалидацию на всякие ресайзы, фреймдропы ( чтоб не было мерцания )
Только desynchronized флаг для 2d включает immediate flush.
где живые примеры? есть код - хотелось бы перейти по ссылке и увидеть, как это работает) обычно делают так. по теме советую почитать ещё вот этот материал https://habr.com/ru/articles/829220/
То есть MessageChannel позволяет передать bitmap (например) по ссылке в другой поток, а не копировать его?
ImageData transferable, так что это единственный способ обмена изолированным кадром.
На деле в статье ошибка. transferControlToOffscreen отдаёт УПРАВЛЕНИЕ, картинка как была на холсте - так и останется. Если сконструировать OffscreenCanvas вручную - тогда забиндить на Dom канвас не получится, тогда нужно получить ImageData если требуется.
Причем MessageChannel вообще тут не упёрся. Межпотокове host<-> worker / tab сразу есть, каналы городить нету смысла. Каналы нужны когда у тебя есть например пул воркеров, которые нужно между собой обнкдинять - порты прокинул, и они пишут в нужные сами, SharedWorkers.
OffscreenCanvas в JavaScript: разгоняем графику до максимума