Clipping image in android

Clipping in Android. Quickly, qualitatively, cheap.

Hey, I’m Dmitriy Дмитрий Гайдук and I am wokring as an adroid-developer in KODE for more than three years.

Quite often, during mobile app developing process it is required to give the content some form, for example, to make a round image for the avatar. If such a tool like Picasso transformation is enough for ImageView, then it is more difficult for dynamic content. For example, there is a list of elements that can be scrolled and need to be clipped. For this, the CardView widget may well be appropriate.

But what if you need a form other than a rectangle, and at the same time, this form will be dynamically changed? It is the exact case from one of our ongoing projects. I couldn’t find proper UI components and decided to research what Android tools are appropriate for this case.

This is a longread — so the main part as usual in the end of the article.

Prototypes

Our designers are really creative. Sometimes their crazy ideas could puzzle even the most experienced developer. Look at what they prepared this time.

There is a card with some content, which could be scrolled. The card has rounded upper corners and lower corners remain straight. It is possible to pull the card up and when the card fills the entire screen, the rounding is removed. Really easy, at first sight, of course.

Easy way

You can use CardView, but there are some disadvantages which I found during coding:

• you can not set the radius for each corner separately;
• “fair” clipping works only on versions starting from Android Lollipop. Before this version, the content is indented by the size of the corner radius. This is noticeable when scrolling, spaces appear between the edges of the card;
• setting zero radius, an application running on a device with a version below Andrid Lollipop crashes. In the documentation, such cases are simply not described.

Thorny path

So, standart widget is useless. It’s time to look for the propriate way out and develop the tool by yourself. But first of all, we need to sort out woth all possibilities for this case in other Android tools.

Criteria for implementing the tool:

• ability to use at Android versions before and after Lollipop. In extreme cases, to combine approaches;
• ability to set any form. For example, using the Path class;
• presence of smooth lines and the possibility of antialiasing;
• performance. The shaping of the content should occur with minimal impact on the performance of the device, especially for dynamically changing content and form.

Of course, it is an ideal version of the tool. I researched 4 differents variants and all of them has pros and cons, but they are suitable for part of cases:

• View.clipToOutline
• Canvas.clipPath() method when rendering elements in container.
• Canvas.drawPath() method when rendering elements in container. Settings: PorterDuff.Mode + View.LAYER_TYPE_SOFTWARE
• Canvas.drawPath()method when rendering elements in container. Settings: PorterDuff.Mode + View.LAYER_TYPE_HARDWARE

View.clipToOutline

This is how CardView works.

How it works:
Set the background image of the desired form and set it in View.clipToOutline value = “true”.
We know that we work with API Android and the easiest way couldn’t be right. Look at documentation View.setClipToOutline()

Sets whether the View’s Outline should be used to clip the contents of the View…Note that this flag will only be respected if the View’s Outline returns true from Outline.canClip()

It is enough for Outline.canClip() to return true . Look documentation for this method too:

Returns whether the outline can be used to clip a View. Currently, only Outlines that can be represented as a rectangle, circle, or round rect support clipping.

So there are quite limited set of forms and it couldn’t realize all requirements of design.
To dynamically change the shape of the background image, you can create a class derived from Drawable. In getOutline() method set the desired outline.

• Good performance
• Line smoothing.

• Works only on Lollipop version and higher;
• Only a rectangle, an oval, and a rectangle with rounded corners

Suitable for cases whan the app is developed for Android Lollipop or higher version and you you need to set the shape of a rectangle, an oval and a rectangle with rounded corners. Perhaps in the future there will be support for any form of contour.

Canvas.clipPath() method rendering elements in container

This variant requires inheritance from container class. In dispatchDraw() method do the trimming in the desired shape using Canvas.clipPath() method.

Set the required contour using the object of Path class. The flaws are visible after the launch of the application — there is no antialiasing, and it is unclear how to add it.

• Works on versions before\after Android LOllipop;
• Good perfomance.

The variant is simple to implement and is suitable for cases when you need to add the functionality to the project quickly, and antialiasing is unprincipled.

Canvas.drawPath() method rendering elements in container, View.LAYER_TYPE_SOFTWARE

This variant also requires inheritance from container class. We do trimming to the right shape in dispatchDraw() method using Canvas.drawPath() method with outline and the Paint class object in parameters. Paint object initializes with xfermode property.

PorterDuffXfermode(PorterDuff.Mode.CLEAR) objest allows to cut the desired area on the screen using the blend mode of one image to another. What for then setLayerType(View.LAYER_TYPE_SOFTWARE, null) ? The fact is that this mode does not work correctly in other types of Layer. Otherwise, behind the cropped figure there will be a white background, and we need a transparent one.
Detailed documentation of PorterDuff.

Accordingly, this setup leads to a performance drop. But how critical it is, can be seen on the performance graph.

During testing, it became clear that no longer work things like a shadow at the button. It seems that the problem is in View.LAYER_TYPE_SOFTWARE.

• Works on versions before\after Android Lollipop;
• Smooth lines.

• Bad performance
• The shadow is not displayed on the buttons. It looks like the problem is in View.LAYER_TYPE_SOFTWARE;
• Not all types of PorterDuff.Mode work

Canvas.drawPath() method rendering elements in container, View.LAYER_TYPE_HARDWARE

The key point, as in the previous approach, is overriding the dispatchDraw () method, in which we use the canvas.drawPath () method for trimming. We set up the View.LAYER_TYPE_HARDWARE for PorterDuffXfermode correct work, you need to add additional logic with the Canvas object in the dispatchDraw () method. Thanks for the hint Ilya Nekrasov

• Works on versions before\after Android Lollipop;
• Good performance;
• Smooth lines.

• If there are two View in container and Alpha changes in each of them, then flicker sometimes occurs. There is no flicker in any version of Android before Lollipop.

To solve the problem with clipping in our project, we used this method. We got rid of flickering when switching between screens, by creation a container for each screen. This affected the performance when changing screens, but not critical and almost imperceptible, since the transition takes less than a second.

Источник

Masking Bitmaps на Android

При разработке под Android довольно часто возникает задача наложить маску на изображение. Чаще всего требуется закруглить углы у фотографий или сделать изображение полностью круглым. Но иногда применяются маски и более сложной формы.

В этой статье я хочу проанализировать имеющиеся в арсенале Android-разработчика средства для решения таких задач и выбрать наиболее удачное из них. Статья будет полезна в первую очередь тем, кто столкнулся с необходимостью реализовать наложение маски вручную, не пользуясь сторонними библиотеками.

Я предполагаю, что читатель имеет опыт в разработке под Android и знаком с классами Canvas, Drawable и Bitmap.

Код, используемый в статье, можно найти на GitHub.

Постановка задачи

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

Обычно маска храниться в ресурсах, а изображение загружается по сети, но в нашем примере обе картинки загружаются из ресурсов следующим кодом:

Обратите внимание на .extractAlpha() : этот вызов создает Bitmap с конфигурацией ALPHA_8, значит, на один пиксел расходуется один байт, который кодирует прозрачность этого пиксела. В таком формате очень выгодно хранить маски, так как цветовая информация в них не несет полезной нагрузки и ее можно выкинуть.

Теперь, когда изображения загружены, можно переходить к самому интересному — накладыванию маски. Какие средства для этого могут применяться?

PorterDuff modes

Одним из предлагаемых решений может стать использование PorterDuff-режимов наложения изображения на холст (Canvas). Давайте освежим в памяти, что это такое.

Теория

Введем обозначения (как в стандарте):

• Da (destination alpha) —исходная прозрачность пиксела холста;
• Dc (destination color) — исходный цвет пиксела холста;
• Sa (source alpha) — прозрачность пиксела накладываемого изображения;
• Sc (source color) — цвет пиксела накладываемого изображения;
• Da’ — прозрачность пискела холста после наложения;
• Dc’ — цвет пискела холста после наложения.

Режим определяется правилом, по которому определяются Da’ и Dc’ в зависимости от Dc, Da,Sa, Sc.

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

[Da’, Dc’] = f(Dc, Da, Sa, Sc)

Например, для режима DST_IN справедливо

Da’ = Sa·Da
Dc’ = Sa·Dc

или в компактной записи [Da’, Dc’] = [Sa·Da, Sa·Dc]. В документации Android это выглядит как

Надеюсь, теперь можно давать ссылку на не в меру лаконичную документацию от Google. Без предварительного объяснения созерцание оной зачастую вводит разработчиков в ступор: developer.android.com/reference/android/graphics/PorterDuff.Mode.html.

Но соображать в уме, как будет выглядеть итоговая картинка по этим формулам, довольно утомительно. Гораздо удобнее воспользоваться вот такой шпаргалкой по режимам наложения:

Из этой шпаргалки сразу видно интересующие нас режимы SRC_IN и DST_IN. Они, по сути, являются пересечением непрозрачных областей холста и накладываемого изображения, при этом DST_IN оставляет цвет холста, а SRC_IN меняет цвет. Если на холсте изначально была отрисована картинка, то выбираем DST_IN. Если на холсте изначально была нарисована маска — выбираем SRC_IN.

Теперь, когда все стало понятно, можно писать код.

SRC_IN

Довольно часто на stackoverflow.com встречаются ответы, где при использовании PorterDuff рекомендуют выделять память под буфер. Иногда даже это предлагается делать при каждом вызове onDraw. Конечно, это крайне неэффективно. Нужно стараться избегать вообще любого выделения памяти на куче в onDraw. Тем более удивительно наблюдать там Bitmap.createBitmap, который запросто может потребовать несколько мегабайт памяти. Простой пример: картинка 640*640 в формате ARGB занимает в памяти более 1,5 Мб.

Чтобы этого избежать, буфер можно выделять заранее и переиспользовать его в вызовах onDraw.
Вот пример Drawable, в которой используется режим SRC_IN. Память под буфер выделяется при изменении размера Drawable.

В примере выше сначала на холст буфера рисуется маска, потом в режиме SRC_IN рисуется картинка.

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

DST_IN

В отличие от SRC_IN, при использовании DST_IN надо изменить порядок рисования: сначала на холст рисуется картинка, а сверху маска. Изменения по сравнению с предыдущим примером будут такие:

Что любопытно, этот код не дает ожидаемого результата, если маска представлена в формате ALPHA_8. Если же она представлена в неэффективном формате ARGB_8888, то все прекрасно. Вопрос на stackoverflow.com на данный момент висит без ответа. Если кто-то знает причину — просьба поделиться знанием в комментариях.

CLEAR + DST_OVER

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

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

Для этого в холсте мы как бы прорезаем дырку по форме маски с помощью режима CLEAR, а затем рисуем картинку в режиме DST_OVER — образно говоря, подкладываем картинку под холст. Через эту дырку видно картинку и эффект получается как раз такой, как нам нужно.

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

Код будет выглядеть так:

У этого решения есть проблемы с прозрачностью. Если мы захотим реализовать метод setAlpha, то через изображение будет просвечивать фон окна, а вовсе не то, что было нарисовано на холсте под нашим Drawable. Сравните изображения:

Слева — как должно быть, справа — как получается, если использовать CLEAR + DST_OVER в комбинации с полупрозрачностью.

Как видим, использование режимов PorterDuff на Android связано либо с выделением лишней памяти, либо с ограничением применения. К счастью, есть способ избежать всех этих проблем. Достаточно воспользоваться BitmapShader.

BitmapShader

Обычно, когда упоминаются шейдеры, вспоминают OpenGL. Но не стоит пугаться, использование BitmapShader на Android не требует от разработчика знаний в этой области. По сути, реализации android.graphics.Shader описывают алгоритм, который определяет цвет каждого пиксела, то есть являются пискельными шейдерами.

Как их использовать? Очень просто: если шейдер зарядить в Paint, то все, что рисуется с помощью этого Paint, будет брать цвет пикселов из шейдера. В пакете есть реализации шейдеров для рисования градиентов, комбинирования других шейдеров и (самый полезный в контексте нашей задачи) BitmapShader, который инициализируется с помощью Bitmap. Такой шейдер возвращает цвет соответствующих пикселов из Bitmap, которое было передано при инициализации.

В документации есть важное уточнение: рисовать шейдером можно все, кроме Bitmap. На самом деле, если Bitmap в формате ALPHA_8, то при отрисовке такого Bitmap с помощью шейдера все прекрасно работает. А наша маска как раз в таком формате, так давайте попробуем отобразить маску с помощью шейдера, который использует изображения цветка.

• создаем BitmapShader, в который загружаем изображение цветка;
• создаем Paint, в который заряжаем этот BitmapShader;
• рисуем маску с помощью этого Paint.

Все очень просто, не так ли? На самом деле, если размеры маски и изображения не совпадают, то мы увидим не совсем то, что ожидали. Маска будет замощена изображениями, что соответствует использованному режиму Shader.TileMode.REPEAT .

Чтобы привести размер картинки к размеру маски, можно воспользоваться методом android.graphics.Shader#setLocalMatrix, в который нужно передать матрицу преобразования. К счастью, вспоминать курс аналитической геометрии не придется: класс android.graphics.Matrix содержит удобные методы формирования матрицы. Будем сжимать шейдер так, чтобы изображение полностью поместилось в маску без искажений пропорций, и сдвинем его так, чтобы совместить центры изображения и маски:

Также использование шейдера дает нам возможность легко реализовать методы изменения прозрачности нашего Drawable и установки ColorFilter. Достаточно вызвать одноименные методы шейдера.

На мой взгляд, это самое удачное решение задачи: не требуется выделение буфера, нет проблем с прозрачностью. Более того, если маска простой геометрической формы, то можно отказаться от загрузки Bitmap с маской и рисовать маску программно. Это позволит сэкономить память, необходимую для хранения маски в виде Bitmap.

Например, используемая в этой статье в качестве примера маска — это довольно простая геометрическая фигура, которую несложно отрисовать.

Поскольку шейдер можно использовать для рисования чего угодно, то можно попробовать нарисовать текст, например:

RoundedBitmapDrawable

Полезно знать о существовании в Support Library класса RoundedBitmapDrawable. Он может пригодиться, если нужно только скруглить края или сделать картинку полностью круглой. Внутри используется BitmapShader.

Производительность

Давайте посмотрим, как перечисленные выше решения влияют на производительность. Для этого я использовал RecyclerView с сотней элементов. Графики GPU monitor сняты при быстром скроллинге на достаточно производительном смартфоне (Moto X Style).

Напомню, что на графиках по оси абсцисс — время, по оси ординат — количество миллисекунд, затраченное на отрисовку каждого кадра. В идеале график должен помещаться ниже зеленой линии, что соответствует 60 FPS.

Plain BitmapDrawable (no masking)

Видно, что использование BitmapShader позволяет добиться такого же высокого фреймрейта, что и без накладывания маски вообще. В то время как SRC_IN решение уже нельзя признать достаточно производительным, интерфейс ощутимо «подтормаживает» при быстром скроллинге, что подтверждается графиком: многие кадры отрисовываются дольше 16 мс, а некоторые и больше 33 мс, то есть FPS падает ниже 30.

Выводы

На мой взгляд, преимущества подхода с использованием BitmapShader очевидны: не надо выделять память под буфер, отличная гибкость, поддержка полупрозрачности, высокая производительность.
Неудивительно, что именно этот подход используется в библиотечных реализациях.

Источник