Кратко, это метод ускорить Криту в 5-10 раз для большинства пользовательских историй.
Пример с 10k, конечно, сильно утрирован. Но представьте, что вам нужно нарисовать иллюстрацию формата А4 600dpi (7k x 5k), или сделать фон для кино формата 4k. Во всех этих случаях работа с уровнями детализации очень сильно упростит процесс. Ускорение в 4-16 раз это не шутки. Это не какое-нибудь SSE/AVX, которое дает прирост в среднем 2-3 раза ;) Более того, ведь в Крите кроме рисования еще есть фильтры. Они тоже ускорятся, в том числе и предварительный просмотр.
ак это может и не «течёт» вовсе — есть такие вещи как кэши и history. Всё это тоже занимает память.
Вы-то писали про «потом закрыл их но оставил только GUI висеть, и потребление памяти при этом продолжало расти, а потом лезть в файл подкачки». А вовсе не про то что сейчас попробовали.
У нас в Крите была похожая ситуация. Дело в том, что тайлы изображения хранятся в общем пуле (boost::pool в нашем случае), и, по хорошему, его нужно освободить при закрытии изображения. Однако есть одна трудность, когда пул имеет размер 2-3Гб, его очистка и высвобождение лишней памяти, если он непустой, занимает порядка 1-2 *минуты* времени. Соответственно, на практике, его можно либо удалить целиком (если повезло и он пустой), либо оставить как есть и вторично использовать память, если там что-то осталось. Так вот очень часто получается так, что даже при закрытии изображения, некоторые GUI элементы продолжают хранить color-managed изображения, никак не связанные с этим закрытым изображением. Соответственно память никуда не возвращается и используется вторично.
В данной ситуации важно различать два варианта развития событий:
При закрыти изображения память не освобождается, однако при открытии заново никуда не растет. Это нормальная ситуация, просто пул остался и используется вторично. Ничто никуда не утекло.
При закрыти изображения память не освобождается, а при открытии заново растет дальше. Это стопроцентно либо прямая утечка, либо забытый shared pointer, либо тупо фрагментация памяти (может достигать 100% если использовать стандартный libc)
Судя по описанному aikixd кейсу, в этой конкретной версии фотошопа именно второй сценарий и именно бага.
1) Докеры. Мы стараемся их улучшать по ходу работы. Если есть конкретные идеи/предложения, что плохо/нужно исправить, пишите, будем смотреть. Вариант «все плохо, сделайте как в фотошопе» не пойдет.
2) Многие вещи в Крите работают по-другому, поэтому и дефолтные шорткаты другие. Например, у нас есть 4 вида пипетки, которые включаются сочетаниями Ctrl+[Alt+]+Left/Right Button из любой кисти. Или, например, изменение размера кисти с помощью клавиши Shift. В фотошопе такого нет в принципе, поэтому там висят другие вещи. Для остального, нужен просто список сочетаний, которых вам не хватает. И мы сможем сделать дефолтный профиль для фотошопных художников.
3) Конкретно с «resize image / resize canvas» согласен.
4) Эрм… у меня пипетка работает. Как при переключении, так и с Ctrl'ом. Никаких тормозов нет.
Гимп — он больше для фотографий и обработки готовых изображений, Крита — создание русунков с нуля, т.е. для художников. Paint.NET… он как минимум Windows-only.
В Крите есть возможность работать с разными не-RGB цветовыми пространствами, возможность рисовать изображения в HDR (Фотошоп этого пока не умеет, если что), инструменты трансформаций на порядок быстрее, чем в Гимпе. Ну и конечно же около 15-ти разных кистевых движков, которые позволяют получать практически любые эффекты, которые нужны художнику.
First Stretch Goal: If we double the amount we can have double the number of full-time people working on Krita! This means that if we can hit 35,000 euro, we can handle 24 features in 6 months!
Super Stretch Goal: if you break the ceiling and make us go to 75.000 euros, we will port Krita to OSX as well. OS X lovers — this is your chance to get Krita on OSX! (To compare, porting Krita to Windows and making it stable needed at least 60.000 euros, but we'll be able to leverage the work done then for the OSX port!)
К сожалению, мы не набрали на «Super Stretch Goal». И как мы поняли набрать на нее целиком за счет одного Кикстартера будет тяжело, поэтому в этой кампании даже не заявляем ее как стреч-цель. Мы будем думать об OSX (точно так же как и о версии для Windows 10) после порта на Qt5, который как раз начался около месяца назад.
Дополнительные средства были потрачены на «First Stretch Goal». Мы выполнили около 18 пунктов из перечисленного в кампании, что даже немного больше обещанного.
По поводу стилей слоев. Первая их версия будет доступна уже в эту среду с релизом 2.9.4 (уже выложены в наших testing репозитариях). А анимация, это отдельный проект никак с ними не связанный.
Это руководство написано Давидом Ревуа, активным пользователем коммьюнити, который помогает разработчикам и поэтому, фактически, описывает, как создать окружение разработчика, чтобы можно было смотреть самые свежие сборки, тестировать патчи и давать обратную связь. Для данного юзкейса checkinstall не подходит, и уж тем более не подходит сборка пакетов манифестами/pbuilder'ом. Для тех, кому нужны пакеты, у нас есть Krita Lime и репозитарии для openSUSE.
Ответ на вопрос «Зачем?»:
1) Пакет, собранный checkinstall, нужно каждый раз ставить и удалять. Когда мы просим пользователя протестировать патч, а потом еще один, а потом еще один поверх предыдущих двух (ну мало ли, может, у него какой-то китайский ноунейм планшет, который говорит, что он клавиатура, и мы должны его все-таки как-то подцепить), установка и удаление пакетов сильно замедлят процесс.
2) 'make install' можно запускать из поддиректорий проекта, устанавливая только его часть. Полная установка Криты RelWithDebInfo занимает 750 МБ, поэтому полноценный запуск 'make install' может занимать до двух минут времени. При работе с патчами это напрягает.
3) Права суперпользователя. Инструкция для котанов, прав суперпользователя здесь лучше избежать.
4) Я говорил про несколько одновременных установок Криты. То есть то, какая версия сейчас запустится, определяется лишь переменными окружения, установленными в текущем терминале. Смысл ставить checkinstall'ом несколько пакетов в разные префиксы, если они все-равно по умолчанию в системе недоступны? Это только создаст путаницу с именами пакетов/директорий.
Да, в этом руководстве про установку нескольких версий Криты нет ни слова. Но некоторые пользователи это используют, и у нас даже есть дополнение к этому руководству для этого (пока не оформлено как следует).
А по поводу
Мжоно вобоще свой манифест написать и крутить как хочешь
Ну вообще-то это руководство не предназначено для продвинутых пользователей, которые могут самостоятельно решить все проблемы, возникающие при сборке пакетов на разных системах. Тем более, что манифесты и control-файлы сильно отличаются в зависимости от дистрибутива. Для одной только Ubuntu у нас два вида control-файлов: для Precise и для всех остальных.
С checkinstall'ом нельзя сделать несколько одновременных установок Криты из разных веток. А так можно установить в разные префиксы и из разных терминалов запускать разные версии. Плюс этот метод позволяет легко быстро применять/тестировать патчи от разработчиков ;)
А есть какой-нибудь хороший и подробный мануал на этот mxe? У нас есть в планах автоматизировать процесс сборки, но пока все не хватает времени заняться.
Когда последний раз пробовали с MinGW (года два назад), выводы были такие:
1) Бинарники получались слишком большого размера
2) Бинарники работали очень медленно
3) Были какие-то проблемы со сборкой 64-битных бинарников, т.е. нормально собирались и работали только 32 бита
После этих экспериментов мы перешли на VS2010, а чуть позже на VS2012. К MinGW с тех пор не возвращались.
Крита — опенсорс. Если у вас есть желание заняться сборкой и поддержкой этих пакетов, напишите нам на IRC, мы с удовольствием расскажем Вам, как это сделать. Только будьте сразу готовы выделить на это сразу 3-4 дня своей жизни. Одна только компиляция зависимостей без учета проблем с древностью XP занимает около двух суток. А там еще и Visual Studio 2012 не работает, так что еще придется потратить время на объяснение компилятору Visual Studio 2010, что такое современный C++…
1) Отсутствие обновленных библиотек от самой Microsoft для Windows XP. Из-за отсутствия рантаймов и нормального инсталлятора MSI (было что-то с зависимостями), каждый пакет собирали фактически вручную, каждый раз разрешая новые проблемы и конфликты.
2) Отсутствие перспектив обновлений для кривых драйверов, которые трактовали стандарты openGL и Wintab весьма фривольно.
3) Фактическое свертывание поддержки Windows XP в Qt 4/5. Технически, он поддерживается, и вроде даже тестируется приемочными тестами, но это уже мало кого интересует.
Решать все эти проблемы самим, ради поддержки мертвой системы, нецелесообразно.
1) Есть Freehand Path Tool, он может рисовать произвольные векторные линии, но вот толщину привязывать к нажатию пока, к сожалению, не умеет.
2) Незамкнутых заливок пока нет. Люди не проголосовали за это на прошлом Кикстартере.
3) Не выходя за лайн… Надо где-нибудь записать… Я уже где-то такое слышал.
1) Векторные инструменты есть, но они очень базовые, т.к. мы им почти не уделяем внимания.
2) С заливками не очень понял, можно пример?
3) PSD импорт/экспорт есть. Не весь функционал совместим, но использовать можно.
1) Флешка теряется не на работе, а на мероприятии.
2) Нашедшие люди ее открывают, ищут фотки/контакты потерявшего человека, параллельно давая клич в группах, связанных с мероприятием, с примерным описанием содержимого.
3) Потерявший находится и радуется воссоединению с родной флешкой.
Я был свидетелем двух случаев, когда владельцы были найдены таким образом. При этом в одном случае из двух там были скинуты фотографии, которые нельзя было восстановить.
Боюсь, что такие разработки просто демотивируют людей помогать в подобных ситуациях.
Замечательный пример: SuperCity. Все текстуры выполнены в некой Крите, рендеринг в каком-то Блендере. И между прочим входит в список Facebook's 2014 Best New Games. Студия из Питера, если что.
Пример с 10k, конечно, сильно утрирован. Но представьте, что вам нужно нарисовать иллюстрацию формата А4 600dpi (7k x 5k), или сделать фон для кино формата 4k. Во всех этих случаях работа с уровнями детализации очень сильно упростит процесс. Ускорение в 4-16 раз это не шутки. Это не какое-нибудь SSE/AVX, которое дает прирост в среднем 2-3 раза ;) Более того, ведь в Крите кроме рисования еще есть фильтры. Они тоже ускорятся, в том числе и предварительный просмотр.
У нас в Крите была похожая ситуация. Дело в том, что тайлы изображения хранятся в общем пуле (boost::pool в нашем случае), и, по хорошему, его нужно освободить при закрытии изображения. Однако есть одна трудность, когда пул имеет размер 2-3Гб, его очистка и высвобождение лишней памяти, если он непустой, занимает порядка 1-2 *минуты* времени. Соответственно, на практике, его можно либо удалить целиком (если повезло и он пустой), либо оставить как есть и вторично использовать память, если там что-то осталось. Так вот очень часто получается так, что даже при закрытии изображения, некоторые GUI элементы продолжают хранить color-managed изображения, никак не связанные с этим закрытым изображением. Соответственно память никуда не возвращается и используется вторично.
В данной ситуации важно различать два варианта развития событий:
Судя по описанному aikixd кейсу, в этой конкретной версии фотошопа именно второй сценарий и именно бага.
2) Многие вещи в Крите работают по-другому, поэтому и дефолтные шорткаты другие. Например, у нас есть 4 вида пипетки, которые включаются сочетаниями Ctrl+[Alt+]+Left/Right Button из любой кисти. Или, например, изменение размера кисти с помощью клавиши Shift. В фотошопе такого нет в принципе, поэтому там висят другие вещи. Для остального, нужен просто список сочетаний, которых вам не хватает. И мы сможем сделать дефолтный профиль для фотошопных художников.
3) Конкретно с «resize image / resize canvas» согласен.
4) Эрм… у меня пипетка работает. Как при переключении, так и с Ctrl'ом. Никаких тормозов нет.
В Крите есть возможность работать с разными не-RGB цветовыми пространствами, возможность рисовать изображения в HDR (Фотошоп этого пока не умеет, если что), инструменты трансформаций на порядок быстрее, чем в Гимпе. Ну и конечно же около 15-ти разных кистевых движков, которые позволяют получать практически любые эффекты, которые нужны художнику.
К сожалению, мы не набрали на «Super Stretch Goal». И как мы поняли набрать на нее целиком за счет одного Кикстартера будет тяжело, поэтому в этой кампании даже не заявляем ее как стреч-цель. Мы будем думать об OSX (точно так же как и о версии для Windows 10) после порта на Qt5, который как раз начался около месяца назад.
Дополнительные средства были потрачены на «First Stretch Goal». Мы выполнили около 18 пунктов из перечисленного в кампании, что даже немного больше обещанного.
По поводу стилей слоев. Первая их версия будет доступна уже в эту среду с релизом 2.9.4 (уже выложены в наших testing репозитариях). А анимация, это отдельный проект никак с ними не связанный.
Ответ на вопрос «Зачем?»:
1) Пакет, собранный checkinstall, нужно каждый раз ставить и удалять. Когда мы просим пользователя протестировать патч, а потом еще один, а потом еще один поверх предыдущих двух (ну мало ли, может, у него какой-то китайский ноунейм планшет, который говорит, что он клавиатура, и мы должны его все-таки как-то подцепить), установка и удаление пакетов сильно замедлят процесс.
2) 'make install' можно запускать из поддиректорий проекта, устанавливая только его часть. Полная установка Криты RelWithDebInfo занимает 750 МБ, поэтому полноценный запуск 'make install' может занимать до двух минут времени. При работе с патчами это напрягает.
3) Права суперпользователя. Инструкция для котанов, прав суперпользователя здесь лучше избежать.
4) Я говорил про несколько одновременных установок Криты. То есть то, какая версия сейчас запустится, определяется лишь переменными окружения, установленными в текущем терминале. Смысл ставить checkinstall'ом несколько пакетов в разные префиксы, если они все-равно по умолчанию в системе недоступны? Это только создаст путаницу с именами пакетов/директорий.
Да, в этом руководстве про установку нескольких версий Криты нет ни слова. Но некоторые пользователи это используют, и у нас даже есть дополнение к этому руководству для этого (пока не оформлено как следует).
А по поводу Ну вообще-то это руководство не предназначено для продвинутых пользователей, которые могут самостоятельно решить все проблемы, возникающие при сборке пакетов на разных системах. Тем более, что манифесты и control-файлы сильно отличаются в зависимости от дистрибутива. Для одной только Ubuntu у нас два вида control-файлов: для Precise и для всех остальных.
1) Бинарники получались слишком большого размера
2) Бинарники работали очень медленно
3) Были какие-то проблемы со сборкой 64-битных бинарников, т.е. нормально собирались и работали только 32 бита
После этих экспериментов мы перешли на VS2010, а чуть позже на VS2012. К MinGW с тех пор не возвращались.
download.kde.org/stable/krita/
Ссылку специально убрали, чтобы баги из неподдерживаемых версий больше не приходили :)
1) Отсутствие обновленных библиотек от самой Microsoft для Windows XP. Из-за отсутствия рантаймов и нормального инсталлятора MSI (было что-то с зависимостями), каждый пакет собирали фактически вручную, каждый раз разрешая новые проблемы и конфликты.
2) Отсутствие перспектив обновлений для
кривыхдрайверов, которые трактовали стандарты openGL и Wintab весьма фривольно.3) Фактическое свертывание поддержки Windows XP в Qt 4/5. Технически, он поддерживается, и вроде даже тестируется приемочными тестами, но это уже мало кого интересует.
Решать все эти проблемы самим, ради поддержки мертвой системы, нецелесообразно.
2) Незамкнутых заливок пока нет. Люди не проголосовали за это на прошлом Кикстартере.
3) Не выходя за лайн… Надо где-нибудь записать… Я уже где-то такое слышал.
2) С заливками не очень понял, можно пример?
3) PSD импорт/экспорт есть. Не весь функционал совместим, но использовать можно.
Ссылки на Windows версию есть в конце статьи :)
1) Флешка теряется не на работе, а на мероприятии.
2) Нашедшие люди ее открывают, ищут фотки/контакты потерявшего человека, параллельно давая клич в группах, связанных с мероприятием, с примерным описанием содержимого.
3) Потерявший находится и радуется воссоединению с родной флешкой.
Я был свидетелем двух случаев, когда владельцы были найдены таким образом. При этом в одном случае из двух там были скинуты фотографии, которые нельзя было восстановить.
Боюсь, что такие разработки просто демотивируют людей помогать в подобных ситуациях.
Если нужно найти знающих людей, обращайтесь!