А можно в виде багрепорта на багзиллу на bugs.kde.org? Желательно сразу предоставить информацию вот по этому мануалу: ссылка. Ну или хотя бы видео и информацию о железе. Ссылку на багу желательно продублировать мне в личку.
Эрм… а можно видео такого поведения? Или хотя бы иллюстрацию? Сделать это достаточно просто, только я не очень понимаю юзкейса. Если объясните зачем, можно обсудить.
Могу добавить лишь то, что за последние два года в Крите было сделано наверное больше, чем за все почти пятнадцать лет ее существования. Были исправлены проблемы, которые висели годами. Взять хотя бы панель слоев :)
Если сможете нарисовать концепт GUI для Криты и прикрепить туда же, то будет совсем здорово. Тогда реализовать будет намного проще. А так, как нибудь позже займусь.
А как GUI выглядит можно скрин? Или ссылку на мануал? И как такие картинки с неровным FPS потом экспортируются? Или он в итоге линеаризуется к наименьшему общему делителю?
Мне кажется, вы не тот пакет установили. Это сообщение было в Крите времен 2.8, а потом его убрали. Появлялось оно, когда были проблемы с установкой и нужно было перезапустить kbuildsycoca4. А так как проблема возникала обычно под виндой, то и .exe приписали. Wine'а никакого конечно же нет :)
В общем, нужно поставить нормальный пакет (если Ubuntu) или собрать из исходников, если не-ubuntu.
Кривую ФПС от времени сделать можно. Я, правда, если честно, нигде такой штуки не видел. Есть примеры? Обычно бывают только инструменты «растягивания» кадров. Их мы обязательно сделаем, сейчас только нужно понять, в каком виде они нужны :) На данный момент растяжение отдельного кадра доступно через Alt+перетаскование.
А про подлгагивания, проверьте, чтобы у вас был включен openGL.
Просто включите ластик кнопкой «Е» и она это запомнит. Для Криты два кончика стилуса это два отдельных инструмента, на которые можно вешать любые инструменты.
Вообще, вроде в последних версиях хотели, чтобы новые пользователи не смущались, сделать там ластик по-умолчанию. То ли не прошел патч, то ли у вас уже не самая новая версия.
На самом деле у вакомов есть еще «скретная» функция. Windows-версия драйвера еще может возвращать «высоту стилуса над поверхностью планшета», т.е. то, на сколько высоко летает кончик стилуса :) Мы все хотим сделать полноценный аэрограф на этом, на руки не доходят ;)
Да, скорость передачи там хорошая. Всего где-то в полтора раза медленнее, чем в памяти. Проблема в том, что там счет уже шел на единицы memcpy'ев, т.е. каждый лишний трансфер — это уже 10-20% ко времени.
В общем случае задача для нас стоит так. Имеем два буфера А и Б одинакового размера. Их попиксельно нужно объединить и результат записать в буфер Б. Пусть 1 memcpy — это время копирования буфера А в буфер Б. Скорость выполнения операции с применением AVX (1-ой версии) по тестам занимает что-то около 10-12 memcpy. Скорость чистого расчета на (слабеньком) GPU — 5 memcpy. Кроме того, нам нужно передать два буфера туда и один обратно, соответственно нужно добавить еще минимум 3 memcpy. Итого нам остается всего 20% ускорения :(
Я после этого пришел к выводам, что нужно либо целиком переносить все-все-все на GPU (читай, переписать половину Криты), либо менять что-то глобально, но в другом месте…
Хм… интересно. Я тестировал только с CUDA. Там, насколько я понимаю, обязательно нужно выполнять cudaMemcpy()… Может там тоже какая-нибудь опция с прямым доступом есть?
На цифры, конечно, взглянуть было бы очень интересно. А то мои тесты два года назад привели к неутешительным выводам, и мы с тех пор это и забросили.
Цинтик и вакомы, к сожалению, не понимают техник карандашного-кистевого рисунков (когда толщина линии меняется наклоном карандаша или поворотом кисти)
В смысле? И наклон, и поворот они измерять могут, причем очень хорошо. Для артпенов вроде даже есть специальные наконечники со скосами, как реальные срезанные маркеры.
А с курсором, если честно, я все еще не понимаю, в чем проблема и в какую сторону исправлять :)
Мы и без openCV это деление оптимизируем как только возможно. Я даже один раз пробовал заменить его на reciprocal+multiplication. Выигрыш получается около 5-10 процентов. Однако вышестоящая библиотека (Vc) предоставляла интерфейс только для векторного reciprocal, а для скалярного нет. А так как мы должны держать и векторную, и скалярную копии кода (для не выровненных по 8 байт данных), то я забил на эту идею :)
Ну что-то есть такое, но без cintiq'а это не раздражает. Попробуйте отключить курсор. Если поможет и если нужно будет, могу потом написать, чтобы курсор только во время штриха скрывался. Хотя, мне кажется, на синтике он вообще лишний.
Да, даже самая дешевая видеокарта с пассивным охлаждением считает это на 50% быстрее. Единственная проблема, эти 50% съедаются временем пересылки данных между CPU и GPU. Так что нужно либо считать все на CPU как раньше, либо переносить весь конвейер целиком на GPU. Последнее весьма проблематично, сами понимаете :)
Эрм… Скорость аппаратного курсора меньше? Такое может быть?
Как вариант, попробуйте отключить аппаратный курсор. Также можете поэкспериментировать с опцией «Show brush outline while painting». На cintiq ее мне кажется можно смело отключить.
Посмотрите приложение Ease (Мольберт). Возможно, вам будут полезны исходные коды его прототипа. Используются стандартные примитивы xaml-разметки (например, Polyline), рендеринг которых выполняется встроенным видеоадаптером.
Так в том-то и дело, что в Крите штрихи не векторные. И их нельзя представить в виде стандартных примитивов xaml (не проверял, но больше чем уверен). Поэтому растеризация происходит на каждом штрихе хотим мы этого или нет. Пользователь может выбрать произвольную кисть в виде растровой картинки и будь добр, рисуй! ;)
Растровые редакторы на телефоне обычно сильно упрощают рисование и поэтому могут работать быстро. Например, они отказываются от поддержки чего-либо, кроме RGB, ограничивают размер изображения, чтобы он мог поместиться в видеопамять/текстуру и рисуют картинку целиком на GPU. Такой вариант будет работать быстро, но пользователь будет сильно органичен в возможностях.
Крита же поддерживает множество «продвинутых» возможностей. Считайте, что каждая из них добавляет отдельный шаг конвейера и/или уровень абстракций, которые в итоге замедляют работу. Например:
Работа с произвольными цветовыми пространствами: CMYK, Lab, Grayscale, RGB. Добавляет уровень абстракций над данными
Полная поддержка менеджмента цвета по ICC или OCIO. Добавляет дополнительный шаг конвертирования цвета в цветовое пространство монитора перед отображением
Динамичесчкие растровые кисти. Их каждый раз нужно считать, т.к. их размер и форма зависит от силы нажатия стилуса (в мобильных телефонах такого нет). Да, мы генерируем для них мипмапы. Да, мы их кешируем. И все-равно это занимает примерно 30% времени рисования
Простое рисование на многослойном изображении подразумевает под собой, что каждый слой должен быть наложен на все предыдущие. Формула, по которой это делается содержит как минимум одну операцию деления, поэтому этот процесс в 20-30 раз медленнее, чем тупой memcpy. Memcpy на Core i7 2400 работает со скоростью около 8Гб/с. Вот и считайте :)
На самом деле, у нас есть одно место, которое теоретически можно оптимизировать, но я пока не знаю как. Дело в том, что «мазки» рисуются последовательно один поверх другого. Соответственно, при шаге в 10%, оставшиеся 90% пикселов пишутся как минимум дважды-трижды пока не произойдет насыщение. Это можно как-то оптимизировать, отказаться от «мазков» и рисовать сразу целыми линиями. Вот только как сделать, чтобы продолжение штриха можно было рисовать, не удаляя предыдущего куска? Т.е. как сделать этот алгоритм инкрементальным?
Если сможете нарисовать концепт GUI для Криты и прикрепить туда же, то будет совсем здорово. Тогда реализовать будет намного проще. А так, как нибудь позже займусь.
В общем, нужно поставить нормальный пакет (если Ubuntu) или собрать из исходников, если не-ubuntu.
А про подлгагивания, проверьте, чтобы у вас был включен openGL.
Вообще, вроде в последних версиях хотели, чтобы новые пользователи не смущались, сделать там ластик по-умолчанию. То ли не прошел патч, то ли у вас уже не самая новая версия.
Наклон можно подключить к любому параметру кисти через сенсоры:
Если лень возиться, можете воспользоваться любым готовым профилем с меткой Т в ЛВУ и словом «tilt» в названии. К ним всем наклон уже привязан:
В общем случае задача для нас стоит так. Имеем два буфера А и Б одинакового размера. Их попиксельно нужно объединить и результат записать в буфер Б. Пусть 1 memcpy — это время копирования буфера А в буфер Б. Скорость выполнения операции с применением AVX (1-ой версии) по тестам занимает что-то около 10-12 memcpy. Скорость чистого расчета на (слабеньком) GPU — 5 memcpy. Кроме того, нам нужно передать два буфера туда и один обратно, соответственно нужно добавить еще минимум 3 memcpy. Итого нам остается всего 20% ускорения :(
Я после этого пришел к выводам, что нужно либо целиком переносить все-все-все на GPU (читай, переписать половину Криты), либо менять что-то глобально, но в другом месте…
На цифры, конечно, взглянуть было бы очень интересно. А то мои тесты два года назад привели к неутешительным выводам, и мы с тех пор это и забросили.
В смысле? И наклон, и поворот они измерять могут, причем очень хорошо. Для артпенов вроде даже есть специальные наконечники со скосами, как реальные срезанные маркеры.
А с курсором, если честно, я все еще не понимаю, в чем проблема и в какую сторону исправлять :)
Как вариант, попробуйте отключить аппаратный курсор. Также можете поэкспериментировать с опцией «Show brush outline while painting». На cintiq ее мне кажется можно смело отключить.
Так в том-то и дело, что в Крите штрихи не векторные. И их нельзя представить в виде стандартных примитивов xaml (не проверял, но больше чем уверен). Поэтому растеризация происходит на каждом штрихе хотим мы этого или нет. Пользователь может выбрать произвольную кисть в виде растровой картинки и будь добр, рисуй! ;)
Растровые редакторы на телефоне обычно сильно упрощают рисование и поэтому могут работать быстро. Например, они отказываются от поддержки чего-либо, кроме RGB, ограничивают размер изображения, чтобы он мог поместиться в видеопамять/текстуру и рисуют картинку целиком на GPU. Такой вариант будет работать быстро, но пользователь будет сильно органичен в возможностях.
Крита же поддерживает множество «продвинутых» возможностей. Считайте, что каждая из них добавляет отдельный шаг конвейера и/или уровень абстракций, которые в итоге замедляют работу. Например:
На самом деле, у нас есть одно место, которое теоретически можно оптимизировать, но я пока не знаю как. Дело в том, что «мазки» рисуются последовательно один поверх другого. Соответственно, при шаге в 10%, оставшиеся 90% пикселов пишутся как минимум дважды-трижды пока не произойдет насыщение. Это можно как-то оптимизировать, отказаться от «мазков» и рисовать сразу целыми линиями. Вот только как сделать, чтобы продолжение штриха можно было рисовать, не удаляя предыдущего куска? Т.е. как сделать этот алгоритм инкрементальным?