Canvas. 2d-контекст. Z-буфер.
 

Доброго времени суток, "когда" бы Вы не находились в часовом пространстве Земли.
Хотел задать общий вопрос по поводу возможности работы с буфером глубины в canvas'е при "2d" контексте.
Есть ли какая-либо возможность кидать всю пачку изображений на отрисовку, чтобы аппаратно было вычислено, какие пиксели рисовать, а какие не трогать?
Или всё это делать руками, перебирая ImageData всех изображений(ну не всех, это уже дело оптимизации)?
Благодарю.

Rise, Вот я работаю с canvas в HTML. Рисую много картинок. И не хочу отрисовывать сначала фон, потом класть на него детали, а на эти детали ещё что-то рисовать последовательно. Это всё будет перегораживать то, что уже отрисовано. Хочу вычислить финальный результат и кидать его для рисования. Или от этих манипуляций приложение быстрее работать не станет?

Rise, Как минимум, при проверке объектов с большим z-индексом, при полной непрозрачности альфа-канала самого верхнего из найденных слоёв, кидать rgb-данные в ячейку финальной картинки по данным координатам. А далее, через putImageData, принимать изображение и рисовать его.

Rise, но это если руками всё делать...

Rise, Объектом я назвал объект, который таковым является в моём коде.
Ясно, обидно...и нет. Тем интереснее. Спасибо за ответ. Просто сам искал, не нашёл, подумал, плохо искал.
Всего хорошего.

Валес,
для канвы можно указать область рисования (clip), рисовать будет только внутри этой области. Попробуй, может, это ускорит отрисовку. Возможно, канва не будет делать копирование картинки в те области, которые находятся за пределами clip.

на этих картинках есть (полу)прозрачные пиксели?

ну, если нарисовать непрозрачную хрень поверх чего-то уже нарисованного, то выходит, это что-то рисовали зря. Автор спрашивает, как быстренько посчитать, какие области рисовать не надо.

да то что не нарисует, это понятно )
я о том, что если clip - квадратик 10 на 10, а на канву кидаем картинку 200 на 300, то по скорости это должно быть как если бы рисовали картинку 10 на 10..

ну представь, что на нижнем слое какой-нибудь фрактал, а сверху его закрывает черный квадрат. Тогда получится, что фрактал рисовали зря.

Это можно определять режимом наложения - globalCompositeOperation.

ну в общем полезная при наложении - https://developer.mozilla.org/ru/doc...ositeOperation ;)

он тут вообще не причем. Его надо оставить как есть, "source-over". Автору топика интересно, как это всё оптимизировать, и не рисовать те части нижних слоев, которые потом закроются верхними.

Деталь, это может быть 10х10, которая накладывается по указанной координате. А вот как эти детали должны взаимодействовать на холсте, это уже как раз режимом можно определить.

Это зависит от режима(контекста) в котором поступают команды на отрисовку но если вкратце то команды сначала накапливаются и только после этого рисуются и то далеко не всегда.
Перекрытые регионы перерисовыватся не будут.

Люди с зарплатой в 50к $ из крупнейщих IT корпораций в течении десятков лет оптимизируют рендер браузера и канваса в том числе (это про браузерными войны). И тут приходит автор топика и реально думает что у него на скриптовом языке в браузере получится лучше. 99% таких оптимизаций приводят к обратному эффекту.

Если автор действительно хочет оптимизировать то ему нужно начать с отладчика и поиска узких мест.

Оптимизация без причины - признак дурачины.

Вот рисование "сначала фон, потом картинка" - https://jsfiddle.net/3gg1j09y/
А вот - как ты предложил - https://jsfiddle.net/ojxtsode/