+, я всегда делаю frameless окна, потому что убогий виндовский топбар это такой ужас

что сам рисуешь, покажи?

+, я всегда делаю frameless окна, потому что убогий виндовский топбар это такой ужас

главное маковские элементы не делай сам

А как при frameless можно убрать скругление рамки в win 7? Его сразу при запуске нет, а если максимизировать и потом минимизировать обратно, появляется.

Есть сайт в нем есть редактирование картинки в реальном времени при помощи Js так вот подключилолся к нему через Webview, но время от времени оно немного подтормаживает, мб кто знает как мне оптимизировать работу с сайтом этим?

не использовать вебвью? сделать свой редактор картинок?

Оно так и будет подтормаживать ибо у тебя рендер через вебвью весьма затратная операция

Есть сайт в нем есть редактирование картинки в реальном времени при помощи Js так вот подключилолся к нему через Webview, но время от времени оно немного подтормаживает, мб кто знает как мне оптимизировать работу с сайтом этим?

Я просто оставлю это здесь https://blog.figma.com/introducing-browserview-for-electron-7b40b4b493d5

@tonyganch Я помню что electron-vibrancy поддерживал регионы ограниченные view которые добавлялись к окну, то есть можно было сделать размытой только боковую панель, а все остальное оставить opaque. Когда все это интегрировалось в электрон, то по моему оставили только возможность выбирать тип vibrancy для всего окна целиком и как то ограничить его действие нельзя? Дело в том, что vibrancy довольно таки не дешевый эффект и если мне нужно сделать только часть окна то как то слишком расточительно выходит делать это для всего окна, а затем маскировать большую облать непрозрачным фоном

мне кажется, что при создании эффекта vibrancy всегда область всегда полностью размывается, а там уже заливается ненужное

если писать браузе на єлектрон, то как лучше вкладки такие как у хрома сделать?

если писать браузе на єлектрон, то как лучше вкладки такие как у хрома сделать?

браузер на браузере…

браузер на браузере…

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

@tonyganch Я помню что electron-vibrancy поддерживал регионы ограниченные view которые добавлялись к окну, то есть можно было сделать размытой только боковую панель, а все остальное оставить opaque. Когда все это интегрировалось в электрон, то по моему оставили только возможность выбирать тип vibrancy для всего окна целиком и как то ограничить его действие нельзя? Дело в том, что vibrancy довольно таки не дешевый эффект и если мне нужно сделать только часть окна то как то слишком расточительно выходит делать это для всего окна, а затем маскировать большую облать непрозрачным фоном

просто заливаешь нужный div нужным цветом (background-color)

просто заливаешь нужный div нужным цветом (background-color)

Я так и делаю. Но меня это не устраивает так как проседает производительность на канвасе раза 4 с full window vibrancy. Я помню экспериментировал с electron-vibrancy, где можно было добавлять регионы и все было в разы производительнее.

Я так и делаю. Но меня это не устраивает так как проседает производительность на канвасе раза 4 с full window vibrancy. Я помню экспериментировал с electron-vibrancy, где можно было добавлять регионы и все было в разы производительнее.

производительность vibrancy на маке неустраивает??

да

лол

MacBook Pro Late 2014 15". Как ни странно не устраивает. Все хорошо, если у тебя обычный UI на React, разницы никакой, но как только присутствует canvas заполняющий 80% окна, вот в нем отзывчивать падает в ~4 раза в сравнении если делать без vibrancy вообще

Потому что, когда включается vibrancy не только backdrop blur начинает работать, кстати который работает на CPU через vDSP/Accelerate framework, потому что для больших радиусов размытия проже использовать IIR а не FIR фильтр, который еще и несколько раз применяется, что бы сымулировать Gaussian blur. Не суть, все что нужно знать vibrancy нагружает CPU а не GPU на Mac-е

+ vibrancy требет еще и transparancy для окна - следовательно еще и fillrate падает

MacBook Pro Late 2014 15". Как ни странно не устраивает. Все хорошо, если у тебя обычный UI на React, разницы никакой, но как только присутствует canvas заполняющий 80% окна, вот в нем отзывчивать падает в ~4 раза в сравнении если делать без vibrancy вообще

А зачем канвас?

А зачем канвас?

Есть Direct Acyclic Graph который быстрее отрисовывть на канвасе а не на svg или DOM

Потому что, когда включается vibrancy не только backdrop blur начинает работать, кстати который работает на CPU через vDSP/Accelerate framework, потому что для больших радиусов размытия проже использовать IIR а не FIR фильтр, который еще и несколько раз применяется, что бы сымулировать Gaussian blur. Не суть, все что нужно знать vibrancy нагружает CPU а не GPU на Mac-е

На счёт vibrancy. Я не верю что он работает на CPU. Учитывая что вся система юзает vibrancy, это было бы максимально глупо

че все так дрочат на vibrancy, говно же ведь

че все так дрочат на vibrancy, говно же ведь

Красиво

На счёт vibrancy. Я не верю что он работает на CPU. Учитывая что вся система юзает vibrancy, это было бы максимально глупо

Поверь) Я знаю о чем говорю

Поверь) Я знаю о чем говорю

Пруфы

да в чем красиво, ну блюрится фон и блюрится, хз

Есть Direct Acyclic Graph который быстрее отрисовывть на канвасе а не на svg или DOM

Ты там рендером графов эффектора занимаешься что ли?

да в чем красиво, ну блюрится фон и блюрится, хз

Vibrancy это не только блюр

эта мода уже несколько раз приходила и уходила

Vibrancy это не только блюр

что еще

что еще

Модификация цветов, контраста, и ещё какой-то эффект, который позволяет белому тексту отображаться нормально, и черному тоже

и весь этот геморр, чтобы тупо картинка на фоне была

кек

Ну да

Пруфы

Вот, только для iOS: https://github.com/KyoheiG3/DynamicBlurView

Вот, только для iOS: https://github.com/KyoheiG3/DynamicBlurView

Эм

и весь этот геморр, чтобы тупо картинка на фоне была

во фронтенде 95% работы чтобы картинки красиво показывать

Да, представь себе на OSX так же

но я не вижу в этом красоты

имеем что имеем, лол

Вот, только для iOS: https://github.com/KyoheiG3/DynamicBlurView

Что мне здесь смотреть надо?

это как челка у айфона

Что мне здесь смотреть надо?

Как это под капотом работает

Как это под капотом работает

Это не значит что во всей системе так

Вот: https://github.com/KyoheiG3/DynamicBlurView/blob/master/DynamicBlurView/CGImage%2BAccelerate.swift#L39

Вот: https://github.com/KyoheiG3/DynamicBlurView/blob/master/DynamicBlurView/CGImage%2BAccelerate.swift#L39

Ну сделано так в либе. Это не доказывает что ос обрабатывает так же. Это не доказывает ровно ничего

Блин, еще раз говорю, в Mac так же, я как то это дебажил на OSX. Там дергается Accelerate framework

На CPU это выходит дешевле для больших радиусов размтия. Перед этим изображение еще даунсэмплиться в 2-4 раза

Пока ссылку в официальную доку с подтверждением твоих слов, нет смысла говорить об этом

Пока ссылку в официальную доку с подтверждением твоих слов, нет смысла говорить об этом

докапываешься

а если это нигде не написано

а если это нигде не написано

Ну тогда это не доказано

Но я считаю что бред

заебись

Пруфов нет — разговор ни о чем

это как говорить, что здание по документам не существует, но оно есть = его все равно не существует

не находишь?

это как говорить, что здание по документам не существует, но оно есть = его все равно не существует

Если здание увидеть можно, значит оно есть

Но в нашем случае в сорцы посмотреть не можем

Значит разговор идёт о здании на закрытом острове

которое может там быть, но скрывается

ERROR: S client not available

которое может там быть, но скрывается

Пока не будет пруфов это лишь сплетни

Я не собираюсь вдаваться в детали и высылать скрины с трейсами вызовов, может сделаю это как время будет. Я задал конкретный вопрос, а вышло уже на 2 страницы флуда

Я не собираюсь вдаваться в детали и высылать скрины с трейсами вызовов, может сделаю это как время будет. Я задал конкретный вопрос, а вышло уже на 2 страницы флуда

Я работал с приложением и vibrancy. Просадок не видел. У меня так же все открытые приложения имеют vibrancy, и все работает ок

Возможно у нас просто разные требования к производительности. Какие приложения? Они использовали сложные графы на канвасе? WebGL и svg не в счет. Первый форсирует переключение на дискретный GPU, а второй и так тормозит на сложных графах

Блин, еще раз говорю, в Mac так же, я как то это дебажил на OSX. Там дергается Accelerate framework

То что дёргается этот фреймворк вообще не пруф. Детали реализации опять же скрыты

То что дёргается этот фреймворк вообще не пруф. Детали реализации опять же скрыты

Тебе показать трейс вызовов?

Возможно у нас просто разные требования к производительности. Какие приложения? Они использовали сложные графы на канвасе? WebGL и svg не в счет. Первый форсирует переключение на дискретный GPU, а второй и так тормозит на сложных графах

Канваса вообще не было. Было дохрена элементов. Ты не думал что тормозит канвас или электрон?

Тебе показать трейс вызовов?

Да, только на macOS

Канваса вообще не было. Было дохрена элементов. Ты не думал что тормозит канвас или электрон?

Опять же я замерял с и без vibrancy - результат координально разный. Так же я делал через electron-vibrancy который умеет ограниченные области вставлять. Блин, ну хватит может уже?)

Опять же я замерял с и без vibrancy - результат координально разный. Так же я делал через electron-vibrancy который умеет ограниченные области вставлять. Блин, ну хватит может уже?)

Причин для тормозов может быть много. Я подвергаю сомнению только одно утверждение.

С тормозами не спорю.

Так же профайлил CoreImage и MetalDevice. У обоих вызывался лишь surface blit (операция копирования на GPU в back buffer) и все

Найти конкретно vImageBoxConvolve не удалось, но все указывает на то, что все операции не покидали cpu host

Почему используется CPU для размытия с большим радиусом (Core Image + vImage/vDSP), а не GPU хорошо продемострировано здесь: http://www.sunsetlakesoftware.com/2013/10/21/optimizing-gaussian-blurs-mobile-gpu

Для больших радиусов размытия GPU становиться не эффективным

Я думаю что через какое то время Apple перепишет это на Metal Compute Shaders но пока видимо они не делают это из-за совместимости

А вот в Windows Aero используется GPU, но там значительно меньше радиус размытия (примерно 16-24px)

пойду почитывать эти методы

спасибо

Это методы преобразования color space и перестановки каналов (типа RGB -> BGR). То что они присутствуют на host cpu уровне хорошо доказывает, что буффер с изображением не отправляется на GPU, так как на GPU эти операции как раз таки очень эффективны

Еще одна причина почему размытие происходит на cpu - это довольно таки дорогая операция пересылки данных от GPU к CPU host и обратно, иногда это намного дороже, чем сделать те же операции на чисто CPU расспаралелив и векторизировав их через SSE

За объяснение большое спасибо!

Да не за что. Я просто довольно плотно когда то занимался image processing и DSP. Поэтому тема с ее проблемами довольно таки знакома)

Создал feature request для этого: https://github.com/electron/electron/issues/13460

как в момент сборки приложения убрать из него DEV зависимости? где почитать?

Эмм, ты думаешь во время сборки электрон рекомпилиться из исходников?) Насколько я знаю во время сборки скачивается просто уже готовая сборка и то, если необходимо