Комментарии 11
Вы перевели сами себя? Алгоритмы интересные, но есть комментарии к реализации:
Подход к fps неверен, так как вместо подсчета каждый кадр вы делаете blur один раз и кэшируете результат тут
далее только рисуется BitmapBrawable, без затрат на blur.
Считаю, что ООП заставляет вынести всю логику в отдельный элемент, который будет назван BlurTextView или BlurLayout, так как вы программно добавляете TextView в контейнер вот тут:
или как минимум в класс BlurUtil, если потребуется использовать его не только для TextView или в рамках Layout.
Если требования к ресурсам и производительности настолько высоки и при открытии фрагмента 50ms мы ждать не можем, можно нарисовать прямо на картинку, которая в ImageView, при этом мы также избавимся от overdraw и лишних затрат по выделению памяти, таких как
Подход к fps неверен, так как вместо подсчета каждый кадр вы делаете blur один раз и кэшируете результат тут
view.setBackground(new BitmapDrawable(
getResources(), overlay))далее только рисуется BitmapBrawable, без затрат на blur.
Считаю, что ООП заставляет вынести всю логику в отдельный элемент, который будет назван BlurTextView или BlurLayout, так как вы программно добавляете TextView в контейнер вот тут:
private TextView addStatusText(ViewGroup container) {
TextView result = new TextView(getActivity());
... container.addView(result); ...
}или как минимум в класс BlurUtil, если потребуется использовать его не только для TextView или в рамках Layout.
Если требования к ресурсам и производительности настолько высоки и при открытии фрагмента 50ms мы ждать не можем, можно нарисовать прямо на картинку, которая в ImageView, при этом мы также избавимся от overdraw и лишних затрат по выделению памяти, таких как
Bitmap bmp = image.getDrawingCache(); // Тут выделится память для картинки размером с image!
Насчет fps — совершенно согласен, но тут скорей я просто выразился неточно. Имелось как раз в виду, что при длительности обработки >16ms начнут пропускаться фреймы. Этот дроп в fps будет наблюдаться только во время работы blur'a. В то же время blur отработает только 1 раз, а потом закешируется.
Насчет ООП — работы тут еще много — т.к. логика в обоих фрагментах одинакова, можно было создать 1 базовый фрагмент и «скармливать» туда что-то вроде интерфейса Blurrer, Оптимизировать и оптимизировать)) Но целью данной статьи небыло создание универсального виджета production-уровня. Я лишь хотел показать с чем едят blur.
Плюс далеко неизвестно кто и как будет использовать blur, поэтому сложно полагаться на тот факт, что размывать мы будем только при создании фрагмента. В данный момент, к примеру, я работаю над куском UI, который размывает фон при показе floating окошка поверх активити. Да и даже, я думаю, найдутся уникалы, которые захотят размывать фон динамически при скроллинге контента (я бы настойчиво не рекомендавал это делать :) ). Вобщем применений может быть масса.
Но а в основном, очень даже валидные комментарии — обновлю GitHub проект как будет время.
Насчет ООП — работы тут еще много — т.к. логика в обоих фрагментах одинакова, можно было создать 1 базовый фрагмент и «скармливать» туда что-то вроде интерфейса Blurrer, Оптимизировать и оптимизировать)) Но целью данной статьи небыло создание универсального виджета production-уровня. Я лишь хотел показать с чем едят blur.
Плюс далеко неизвестно кто и как будет использовать blur, поэтому сложно полагаться на тот факт, что размывать мы будем только при создании фрагмента. В данный момент, к примеру, я работаю над куском UI, который размывает фон при показе floating окошка поверх активити. Да и даже, я думаю, найдутся уникалы, которые захотят размывать фон динамически при скроллинге контента (я бы настойчиво не рекомендавал это делать :) ). Вобщем применений может быть масса.
Но а в основном, очень даже валидные комментарии — обновлю GitHub проект как будет время.
В моем текущем проекте, к сожалению, требуется показывать полупрозрачную панель поверх списка (часть списка под панелью должна выглядеть размытой).
Пользуюсь RenderScript для размытия, получается достаточно быстро, но все равно весь UI заметно подтормаживает. Пока отложил решение этой проблемы (подтормаживание UI) на потом.
Может быть у вас есть идея, как поступать в случае вроде моего? Я понимаю, что лучше всего отговорить заказчика :-), но может есть какие-то другие идеи (судя по всему, вы сталкивались с подобной ситуацией)?
Пользуюсь RenderScript для размытия, получается достаточно быстро, но все равно весь UI заметно подтормаживает. Пока отложил решение этой проблемы (подтормаживание UI) на потом.
Может быть у вас есть идея, как поступать в случае вроде моего? Я понимаю, что лучше всего отговорить заказчика :-), но может есть какие-то другие идеи (судя по всему, вы сталкивались с подобной ситуацией)?
На самом деле даже не пробовал сделать real-time blur. По понятным причинам размывать кусок фона при каждом изменении скрола не вариант :) Но можно попробовать сделать что-то вроде размытия всего экрана (верней той части listView, что в данный момент видна на экране). Как только listView начинает скроллиться, скроллим нашу размытую подложку. Главное расположить layout так, чтобы подложка была видна только под ActionBar (ну или что используется для этих целей), т.е была иллюзия что размывается сам listView. Как только «доезжаем» до края размытой подложки — размываем новую порцию listView (что в данный момент на экране). В данном случае небольшой «лаг» будет заметен при обновлении подложки.
Но, если честно, не уверен, что из этого выйдет что-то хорошее :( Надо пробовать.
В Yahoo Weather сделали хитрый трюк — они не делают новую порцию размытого экрана как только доезжают до края подложки — они оставляют ее на месте. Создается иллюзия динамически размываемого фона, хотя по сути размывают они весь фон только один раз.
Но, если честно, не уверен, что из этого выйдет что-то хорошее :( Надо пробовать.
В Yahoo Weather сделали хитрый трюк — они не делают новую порцию размытого экрана как только доезжают до края подложки — они оставляют ее на месте. Создается иллюзия динамически размываемого фона, хотя по сути размывают они весь фон только один раз.
Кстати наткнулся на то, что Вы как раз ищите: GlassActionBar
Почему бы не реализовать через быстрое преобразование Фурье (ну или Хартли, так как изображение не комплексное, а вещественное)? Должно быть еще быстрее. Ведь это банальная свертка с ядром размытия. А от Гаусса даже Фурье считать не надо, опять будет Гаусс.
Только на прошлой неделе по проекту столкнулся с подобным таском, я его отложил как сложный и не важный, а тут пост на эту тему, здорово)
Огромное спасибо за эту статью! Мне как Андроид-разработчику было очень интересно и полезно почитать. Кто знает, может в следующем приложении нужно будет реализовать размытие.
А есть up-to-date способы размывания активити под диалогом?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем эффективный blur на Android