Comments 11
Обманывать нехорошо. Вы не ускорили приложение с помощью шейдера, а ускорили благодаря отказу от неверного постулата перерисовывать там, где нужно сразу рендерить в текстуру. Так же, сомнительно что прямой фрагментный шейдер, как то сильно вам помогает, тут вообще шейдер-плацебо.
Да, вы правы, что в данном примере использование шейдера не влияет на производительность напрямую. Также сам код шейдера из примера не дает разницы в качестве по сравнению с отрисовкой с помощью метода drawImage() в CustomPainter. Картинка такая же пиксельная, и с виду немного хуже, чем при использовании Image.memory().
Но само использование шейдера дает больше возможностей. Результат можно улучшить, например, добавив в код шейдера антиалиасинг, чтобы появился эффект сглаживания и картинка казалась менее пиксельной. В статье дополнил реализацию шейдера.
Таким образом, шейдер здесь уже как бы для закрепления полученного результата. Иначе из-за потери качества пришлось бы откатить к варианту преобразования в байты и дальнейшей отрисовки через Image.memory(), а это шаг назад в плане производительности.
несомненно, работа с шейдером может добавить дополнительных возможностей. Жаль, что "в руки" не дают связку с вертексным, мне не хватает.
Хотя, в итоге я отказался от встроенных возможностей и я работаю с OpenGl ( вернее и ES GL и WebGL) через текстуру и ffi.
Мне, кстати, очень интересно - вы с тем возможностями, что предоставил Flutter, что планируете реализовывать на шейдерах?
Пока я планирую реализовать только различные варианты кистей для рисования, для этого вполне хватает тех возможностей, которые предоставляет Flutter
Напрямую работать с вершинными шейдерами во Flutter нам не дают, это так. Но по сути API сanvas заменяет нам вершинные шейдеры, позволяя строить изображения из набора примитивов, а затем "натягивать" на них свои фрагментные шейдеры. Этот подход и достаточно "высокоуровневым", чтобы не вникать в тонкости построения изображения из вершин графических примитивов, и предоставляет большое кол-во встроенных методов, чтобы покрыть 95% нужд разработчиков.
Это всё здорово. Но знаете, меня не покидает мысль, о том, что как тоже самое рисовали на ПК 25+ лет, без шейдеров. Это и банальный paint с выбором кистей который в поставке с windows 3.1. Тот старый фотошоп. И это всё работало на процессорах на десять порядков ниже по производительности, без аппаратного ускорения.
К статье претензий нет, просто мысли в слух.
Ну, давайте объективно ответим саме себе на следующие вопросы:
Какое было разрешение экрана и битность цвета?
Разве фотошоп сейчас не использует видеоускоритель?.. А когда не использовал, насколько комфортно было в нём работать и насколько сложные операции поддерживал?
Я помню как мы рисовали 25+ лет назад. Ещё на спекки, писали на асме. И потом, на х86,... Не, не хочется мне в прошлое, сейчас лучше)
Какое было разрешение экрана и битность цвета?
Ходовой в 2000-ые 1024x768
Разве фотошоп сейчас не использует видеоускоритель?.. А когда не использовал, насколько комфортно было в нём работать и насколько сложные операции поддерживал?
Я с фотошоп не работал. Не было необходимости. Ну уж выбор кистей и каляку маляку позволял делать.
Я помню как мы рисовали 25+ лет назад. Ещё на спекки, писали на асме. И потом, на х86,... Не, не хочется мне в прошлое, сейчас лучше)
25 лет назад это 2000-ые. АСМ это ещё лет на десять назад. Pentium 700-1000mhz, 256 ОЗУ. Вполне на то время, комфортное железо. Асм уже не так, часто использовали.
Вообще стало интересно, на сколько тот же paint будет тормозить на похожей картинке. 86box + windows 98. Как раз можно будет выбрать определённый процессор.
Я заметил, что качество при отрисовке картинок в
CustomPainterможет сильно теряться, они как бы становятся пиксельными. Заметно, когда переводишь обычную красивую картинку, например, из ассетов вui.Imageи рисуешь в пейнтере
Что если попробовать использовать FilterQuality? (его можно пробросить в drawImage через Paint.filterQuality) По идее не нужен будет шейдер
Как я повысил производительность flutter приложения с помощью FragmentShader. Часть 2