Assuming 1 million users of VS Code This blinking cursor will waste $3 million per year in electricity costs, and output 32,000 tons of c02 per year.
2150: "Grandpa, why did the ocean's dry up?"
"well sonny, long ago, Microsoft didn't optimize their code for a code editor's cursor and pushed earth's climate over the edge"
Суть:
Это все про Microsoft Visual Code который как известно есть Electron application — Chromium based.
1. Типа bug в самом chromium / webkit: эта анимация исполняется с частотой animation frame rate — each 16ms — 60 FPS.
2. Т.к. Chromium (WebKit со Skia backend) это mostly CPU rasterization то это в общем-то простое действо (fill 1px rectangle) потребляет CPU ресурсы как не в себя. На каждый frame rate перерисовывается всё окно.
Ну и сами авторы VS Code тоже в общем-то виноваты, вместо тривиального односекудного setTimer(blink, 1000) запузырить туда animation.
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle
VSCode 1.10.2 — у меня при любом раскладе выжирает ~<1% (0.2-0.8% в сумме для всех процессов)... правда цифра из task manager бесполезная — зависит от количества ядер. Ну можно умножить на 8.
А вот взрослая студия в "покое" — у меня стабильно жрёт >1%. Сейчас 1.3. А бывает 5. При этом она наглухо свёрнута.
Но этим страдают много кто.
CS>1. Типа bug в самом chromium / webkit: эта анимация исполняется с частотой animation frame rate — each 16ms — 60 FPS.
Баги-багами, но это ещё зависит от editor.cursorBlinking который например может быть smooth и который точно будет требовать точную анимацию.
CS>2. Т.к. Chromium (WebKit со Skia backend) это mostly CPU rasterization то это в общем-то простое действо (fill 1px rectangle) потребляет CPU ресурсы как не в себя. На каждый frame rate перерисовывается всё окно.
Если такое происходит — это точно баг. У меня — перерисовывается только область курсора. Легко проверить через Help -> Toggle Developer Tools. Три точки -> More tools -> Rendering settings:
Друзья:
— Paint Flashing
— Layer Borders
— FPS Meter
FPS meter у меня показывает ~2fps. А вот при "editor.cursorBlinking": "smooth" — уже ~27fps.
Насчет того что перерисовывает "всё" — то это уже от кривизны лайаута и зависит. В худшем случае попадаем на перерисовку слоя (тот который квадрат 256х256 (или 512)), остальное должно отсекаться, если не затрагивается.
Я тут где-то писал — вот в google sheets — кликание по клеткам действительно приводит к перерисовке всего листа из-за того как сделана обводка вокруг ячейки (сейчас лень перепроверять — могли и пофиксить).
Ну а баги... бывают. По хорошему нужно тесты запиливать на такое, потому что — неправильная верстка — привет, мир. Обновили движок — а в нём баг — опять привет мир. Но видать до этого ещё не добрались.
CS>Ну и сами авторы VS Code тоже в общем-то виноваты, вместо тривиального односекудного setTimer(blink, 1000) запузырить туда animation.
Декларативненько ж...
Re[2]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
Здравствуйте, Mystic Artifact, Вы писали:
MA>Если такое происходит — это точно баг. У меня — перерисовывается только область курсора.
Говорят что это в основном на MacOS проявляется.
В любом случае это специфика именно Chrome и его самописного rasterization engine (Skia).
По идее все rendered objects должны сидеть в GPU. Меняется только отсутствие/присутствие того caret bar rectangle.
Т.е. даже в случае 60 FPS update ничего радикального не должно происходить.
Вот в Sciter примерно такое же функциональности окно (editor c syntax highlighting):
Direct2D backend:
А это вот один из rendering процессов VS Code (всего VS Code запускает 8 процессов на это бедное окно):
А это вот все тот же Sciter но со Skia backend — тем же что использует Chromium:
Это все на Win10 где Microsoft сильно отрихтовала OpenGL поддержку (исп. Skia в Sciter). На W7 разница D2D/OpenGL должна быть более значительна.
По твоим картинкам в основном понятно только то, что VSCode делаёт ещё что-то (что и не удивительно).
Отличия понятно, что есть. Ты то сам как курсор рисуешь, и реально к каким перерисовкам приводит его отрисовка?
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking Curs
Я так подозреваю, что 13% — это просто 1/8 процессора. ))) Т.е. по сути речь идёт о 100% загрузке одного ядра — возможно оно и больше могло бы сожрать, просто упёрлось в потолок. ))) Явно баг какой-то. )))
Re[3]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
Здравствуйте, c-smile, Вы писали:
CS>В любом случае это специфика именно Chrome и его самописного rasterization engine (Skia).
вы так написали "самописного" как будто этот енжин вчерашний школьник писал. Скиа не более "самописная" чем Direct2D, Cairo или Sciter К тому же у skia есть разные бекенды, как софтверные так и gpu-accelerated.
CS>По идее все rendered objects должны сидеть в GPU. Меняется только отсутствие/присутствие того caret bar rectangle.
Skia или хром этому не помеха. И вообще очевидно, что хром, затачиваемый в том числе на использование в мобилках, будет как минимум осведомлён о gpu. И уж что-что а оперировать слоями на уровне GPU он может ( чуть подробнее здесь: UI Elements at 60fps )
Re[4]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
Здравствуйте, antropolog, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>В любом случае это специфика именно Chrome и его самописного rasterization engine (Skia). A>вы так написали "самописного" как будто этот енжин вчерашний школьник писал. Скиа не более "самописная" чем Direct2D, Cairo или Sciter К тому же у skia есть разные бекенды, как софтверные так и gpu-accelerated.
"самописный" не означает что его школьник написал. Скорее отражает тот факт что Skia написана как статическая библиотека которая максимально дистанциируется от системных средств.
И эта дистанция имеет цену: там где Direct2D использует JIT для имплементации эффективного rasterization (когда что-то нужно делать на CPU side) Skia надеется на оптимизирующий С/С++ compiler. Что не всегда the case.
Статичность же библиотеки означает то что у неё нет стабильного API — т.е. это сугубо встраиваемая вещь.
Например Android UI использует Skia под капотом, но эта Skia не доступна native приложениям поэтому тот же Chrome на Android использует свою копию Skia.
И хорошо если они обе используют OpenGL в качестве final composition layer а не банальный pixmap в heap. Но если screen может работать с OpenGL напрямую то приложения уже должны работать через OpenGL frame buffer (FBO) что является больным местом OpenGL исторически.
Для эффективного OpenGL hardware acceleration приложение должно быть fullscreen. Что в UI далеко не всегда возможно да и вообще имеет смысл.
CS>>По идее все rendered objects должны сидеть в GPU. Меняется только отсутствие/присутствие того caret bar rectangle. A>Skia или хром этому не помеха. И вообще очевидно, что хром, затачиваемый в том числе на использование в мобилках, будет как минимум осведомлён о gpu. И уж что-что а оперировать слоями на уровне GPU он может ( чуть подробнее здесь: UI Elements at 60fps )
Не понял как это видео соотносится с обсуждаемой темой кроме обсуждения will-change которое на самом деле вообще никому не нужно. Когда исполняется transition всегда есть два property set — start и target. Построить дельту свойств которые отличаются — тривиально. Ну да это все далеко от обсуждаемой темы про hardware acceleration.
Re[2]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
_>Я так подозреваю, что 13% — это просто 1/8 процессора. ))) Т.е. по сути речь идёт о 100% загрузке одного ядра — возможно оно и больше могло бы сожрать, просто упёрлось в потолок. ))) Явно баг какой-то. )))
Не факт. Нужно знать платформу на которой замеры производились.
Дело в том что MacOS измеряет загрузку одного core, а Windows — всего процессора.
Т.е. в Windows цифры загрузки больше 100% невозможны, а в MacOS ты можешь увидеть 200% если процесс загружает два ядра полностью.
Т.е. MacOS/13% это Windows/3.25% что в общем-то близко к аналогичным измерениям MS Code на Windows.
Re[3]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
Здравствуйте, c-smile, Вы писали:
_>>Я так подозреваю, что 13% — это просто 1/8 процессора. ))) Т.е. по сути речь идёт о 100% загрузке одного ядра — возможно оно и больше могло бы сожрать, просто упёрлось в потолок. ))) Явно баг какой-то. ))) CS>Не факт. Нужно знать платформу на которой замеры производились. CS>Дело в том что MacOS измеряет загрузку одного core, а Windows — всего процессора. CS>Т.е. в Windows цифры загрузки больше 100% невозможны, а в MacOS ты можешь увидеть 200% если процесс загружает два ядра полностью. CS>Т.е. MacOS/13% это Windows/3.25% что в общем-то близко к аналогичным измерениям MS Code на Windows.
Так процент от только физических ядер или всё же логических (как на винде)? ) Ну и если речь о 13% от одного логического ядра, то это уже близко к норме для современного сложного ПО (например браузеры обычно столько же едят). )))
Re[5]: Эпическая дискуссия про: VS Code Uses 13% CPU When Id
Здравствуйте, c-smile, Вы писали:
CS>Статичность же библиотеки означает то что у неё нет стабильного API — т.е. это сугубо встраиваемая вещь.
Я не стал обращать внимания, но меня тоже "самописность" возмутила. И вроде бы ж как Skia — как раз родом из андроида, а не хрома. Но это всё ерунда.
Я тут хотел уточнить — что у либы проблемы не со статичностью как таковой, а с тем что она намертво привязана к C++. Не так сильно как V8, но всё же есть.
Отсюда и вся статичность.
Интересный вопрос на самом деле — ведь на DX выходит не хуже у некоторых, а там... никакой магии.
Re: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking Curs
CS>Там две проблемы:
CS>1. Типа bug в самом chromium / webkit: эта анимация исполняется с частотой animation frame rate — each 16ms — 60 FPS. CS>2. Т.к. Chromium (WebKit со Skia backend) это mostly CPU rasterization то это в общем-то простое действо (fill 1px rectangle) потребляет CPU ресурсы как не в себя. На каждый frame rate перерисовывается всё окно.
CS>Ну и сами авторы VS Code тоже в общем-то виноваты, вместо тривиального односекудного setTimer(blink, 1000) запузырить туда animation.
Сначала я посмеялся. А потом, подумавши, решил, что не над чем тут смеяться. Как уже написали выше, их решение декларативное, а не императивное (на языке современных веб-девелоперов: 'pure CSS'). Поэтому, пусть лучше в Хромиуме чинят перф. (В Хроме все нормально).
Единственное, что... Согласно этому списку, им было доступно visibility. В Хромиуме лень проверять, а в Хроме это работает:
Я даже сначала не въехал в прикол, потому, что из-за opacity не увидел step-start (как бы, предполагается linear). Думал, дезигнеры eye-candy добавили, которую таймером никак не сделать. Но я не удивлюсь, если изначально они и планировали linear, а потом по каким-то причинам отказались. Если мое предположение верно, такой подход еще и универсальнее, т.к. в будущем можно добавить настройку "Мигать курсором плавно". Если и это кому-то покажется смешным, я напомню, что для code editor такие нюансы — не последнее дело, я одно время в студии PHP редактировал просто потому, что как текстовой редактор она мне нравилась, хотя PHP никоим боком не поддерживала. А если мое предположение неверно, то, конечно, надо было использовать visibility.
Пользуясь случаем, спрошу у человека, который принимает участие в стандартизации: а зачем вообще (в W3C?) ввели понятие 'animatable property'? Вот тут написано так:
As it doesn't make sense to animate some properties, the list of animatable properties is limited to a finite set.
Тем не менее, легко представить задачу, когда в невидимой фазе элемент не должен занимать места, а display: none; туда не засунуть
Re[2]: Эпическая дискуссия про: VS Code Uses 13% CPU When Idle Due to Blinking C
Здравствуйте, 463C21E2, Вы писали:
CE>Я даже сначала не въехал в прикол, потому, что из-за opacity не увидел step-start (как бы, предполагается linear). Думал, дезигнеры eye-candy добавили, которую таймером никак не сделать. Но я не удивлюсь, если изначально они и планировали linear, а потом по каким-то причинам отказались. Если мое предположение верно, такой подход еще и универсальнее, т.к. в будущем можно добавить настройку "Мигать курсором плавно".
Это уже есть: настройка editor.cursorBlinking (smooth например).