[AI CC-CC2021] Channel Mixer by S.H.

Станислав Хоффман

Участник
Топикстартер
Сообщения
277
Реакции
24
Всем привет, выкладываю свой Channel Mixer - две версии интерфейса.

Channel Mixer by S.H. v1

функционал:
ввод значений в поля вводя
шаг с помощью стрелок курсора вверх/вниз на 1% и 10% с зажатым шифтом.
минимальную точку растра следует вводить с точкой, не запятой.

скрипт не оптимизирован и работает медленно, если в документе много объектов - вставьте перекрашиваемые объекты в новый файл, это значительно ускорит процесс.

Приветствуется помощь по идеям оптимизации и сокращения кода.

p.s. на первые 9 массивов можете не смотреть, сокращу до 3х.

Tabbed version.png Full version.png
 
  • Спасибо
Реакции: Spirit412 и Skvoznyak
да с массивами в принципе проблем нет, хоть девять, хоть три или два.
Надо в профилировщике погонять, там будет понятно в чем дело.
Я бы не стал дергать каждый раз в цикле значения элементов slideCC.value, mCut.text, checkF.value == true - это все же не переменные и доступ к ним может быть дольше. Лучше при всяких движухах их сохранять в переменные и их уже эти переменные использовать при расчетах (хотя могу и ошибаться и производительность не в этом месте теряется).
Опять же при не посмотрел логику, но если при каждом изменении ползунка делается update, то можно сократить расчеты в четыре раза пересчитывая только изменяемый цвет, к примеру C (поскольку нет такого ползунка который влияет на все цвета, кроме мин%).
Нет проверок на то каким типом заливки/обводки обладает объект, это не всегда CMYKColor.
 
да с массивами в принципе проблем нет, хоть девять, хоть три или два.
Надо в профилировщике погонять, там будет понятно в чем дело.
Я бы не стал дергать каждый раз в цикле значения элементов slideCC.value, mCut.text, checkF.value == true - это все же не переменные и доступ к ним может быть дольше. Лучше при всяких движухах их сохранять в переменные и их уже эти переменные использовать при расчетах (хотя могу и ошибаться и производительность не в этом месте теряется).
Опять же при не посмотрел логику, но если при каждом изменении ползунка делается update, то можно сократить расчеты в четыре раза пересчитывая только изменяемый цвет, к примеру C (поскольку нет такого ползунка который влияет на все цвета, кроме мин%).
Нет проверок на то каким типом заливки/обводки обладает объект, это не всегда CMYKColor.
Можно не заморачиваться а через try {} catch закоротить
 
Последнее редактирование:
да с массивами в принципе проблем нет, хоть девять, хоть три или два.
Надо в профилировщике погонять, там будет понятно в чем дело.
Я бы не стал дергать каждый раз в цикле значения элементов slideCC.value, mCut.text, checkF.value == true - это все же не переменные и доступ к ним может быть дольше. Лучше при всяких движухах их сохранять в переменные и их уже эти переменные использовать при расчетах (хотя могу и ошибаться и производительность не в этом месте теряется).
Опять же при не посмотрел логику, но если при каждом изменении ползунка делается update, то можно сократить расчеты в четыре раза пересчитывая только изменяемый цвет, к примеру C (поскольку нет такого ползунка который влияет на все цвета, кроме мин%).
Нет проверок на то каким типом заливки/обводки обладает объект, это не всегда CMYKColor.
мысль о проверке на CMYKColor была, как и на счёт текста - скрипт с ним не работает. Это сделаю.
Верно, при каждом изм. слайдера делается update, он там при каждом чихе делается.
Про сокр. в 4 раза идея хорошая, сделаю.
Производительность тех или иных решений буду замерять через таймер на начало и конец какогото куска кода, я так уже делал оптимизацию старого скрипта и там удалось выжать 30% прироста.
 
Можно не заморачиваться а через try {} catch закоротить
Лучше заморочиться, как минимум можно сразу избавиться от левых объектов и не добавлять их в основой цикл обработки.
Производительность тех или иных решений буду замерять через таймер на начало и конец какогото куска кода
Если запускать через Extended Toolscript, то в меню Profile можно выбрать Lines и все раскладка будет понятна.
 
Лучше заморочиться, как минимум можно сразу избавиться от левых объектов и не добавлять их в основой цикл обработки.

Если запускать через Extended Toolscript, то в меню Profile можно выбрать Lines и все раскладка будет понятна.
кстати, да, на днях читал об этом в мануале, хотел проверить. Спасибо.
 
первое вскрытие показало, что самые тормозные места - это массивы в связке с присвоением цвета и проверкой if:

Код:
if (paths[arr1[i]].filled == true && checkF.value == true) {       

            paths[arr1[i]].fillColor.cyan = finC; //  первый массив
            paths[arr1[i]].fillColor.magenta = finM;
            paths[arr1[i]].fillColor.yellow = finY;
            paths[arr1[i]].fillColor.black = finK;

и функция redraw()
 
Может лучше действовать через Swatches.
ChanMixSw для Illustrator
Этот скрипт работает быстро, хотя написан очень коряво.
Принцип: собираете из помеченного Swath (Swatches-->All Selected Color), далее выделяете нужные Swatch и запускаете скрипт.
 
Этот скрипт работает быстро, хотя написан очень коряво.
Ну это разные классы скриптов, этот тоже в принципе отрабатывает быстро разовое изменение цвета, но только он заточен под постоянную доводку.
На свотчи переделать в принципе можно, изменения не сильно большие.
 
Ну это разные классы скриптов, этот тоже в принципе отрабатывает быстро разовое изменение цвета, но только он заточен под постоянную доводку.
На свотчи переделать в принципе можно, изменения не сильно большие.
Это понятно, что не того уровня скрипт. Это в качестве идеи. По моему опыту, если работает долго -- пользоваться неудобно.
Ну как вариант: через Action в скрипте собрать, а после подчистить свотчи. Тогда не надо перебирать объекты (заливки, обводки).
 
Последнее редактирование:
Ну она вынесена за пределы цикла, так что улучшать тут нечего.
А вот присваивать цвета проще одной операцией
Код:
xxx = new CMYKcolor.
xxx.Cyan = finC;
xxx.Magenta = finM;
paths[arr1[i]].fillColor = xxx;
если redraw поставить перед update, на неё тратиться на ~40% меньше времени.
Если работать с объектами через выделение, будет быстрее, но возникнет проблема с мульти-вложениями объектов в группы.
 
C градиентами не работает, я так понимаю пока. А с Appearance как быть?
 
C градиентами не работает, я так понимаю пока
С градиентами не работает в принципе, это только если через Recolor выводить цвета на свотчи и скрипт переводить на работу с ними.
 
C градиентами не работает, я так понимаю пока. А с Appearance как быть?
пока не работает, занимаюсь. Очень глючная эта штука, градиенты.
Скрипты работают только со стандартным Appearance - одна заливка, одна обводка. Выход - разбивать через Expand Appearance. Или подождать вариант скрипта, который будет работать через свотчи. Надо подумать, как бы обойти ручное добавление свотчей.
 
С градиентами не работает в принципе, это только если через Recolor выводить цвета на свотчи и скрипт переводить на работу с ними.
с градиентами на прошлой неделе развлекался - работает, но очень глючная вещь. Доступ к ним через скриптинг есть, можно прикрутить. Надо прикинуть, что будет лучше - добавить градиенты или добавить свотчи. Если добавить свотчи, скорость работы скрипта возрастёт, в теории.
Алгоритм я вижу такой: выделяем объект, скрипт создаёт свотчи (споты с копированием значений CMYK ?), дёргаем цвета, при закрытии окна автоматом удаляем свотчи.
 
Надо прикинуть, что будет лучше - добавить градиенты или добавить свотчи.
Чтобы изменить градиент, тебе не просто надо его изменить, а добавить новый с нужной раскраской и плюс скопировать все атрибуты... потом при изменении ползунков создавать новый, присваивать объекту, предыдущий промежуточный градиент удалять. И вообще я не уверен что все фишки градиентов доступны через объектную модель.
Я от вариантов работы с градиентами устраняюсь сразу, те кому нужны данные возможности могут потерпеть некоторые неудобства работы через свотчи.
 
Чтобы изменить градиент, тебе не просто надо его изменить, а добавить новый с нужной раскраской и плюс скопировать все атрибуты... потом при изменении ползунков создавать новый, присваивать объекту, предыдущий промежуточный градиент удалять. И вообще я не уверен что все фишки градиентов доступны через объектную модель.
Я от вариантов работы с градиентами устраняюсь сразу, те кому нужны данные возможности могут потерпеть некоторые неудобства работы через свотчи.
согласен, с градиентами возни много. Буду думать в сторону свотчей.