Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Дни Firefox на хабре
Эээ, зачем?
«У Вас садится батарейка, для просмотра видео подключите зарядное устройство»
«У Вас садится батарейка, для просмотра видео подключите зарядное устройство»
Сам спросил, сам ответил.
Battery API + Geolocation API = контекстная реклама «найти ближайшую халявную розетку»
Думайте про веб-приложения. Можно предупредить пользователя, что у него батарейка сейчас сядет, надо закругляться, сохранить результаты работы, выключить полноэкранное видео и так далее.
Думайте о пользователе. Ему система будет пикать/моргать/уведомлять каждые пять минут, а тут ещё и веб приложение.
Что ему система пикать будет? Какая система? Мне «Мак» ничего не пикает, только аккумулятор краснеет. И табличка появляется один раз за 10 минут до выключения.
Ну так приложение не только моргать сможет, но и сохранить черновичок, или, например, уведомить работающих с человеком в одной среде «такой-то может нас скоро покинуть потому, что у него садится батарея».
Теперь можно косвенно определить за каким девайсом сидит человек за десктопом или ноутом. Ждем более точный таргетинг рекламы ноутбуков и условно-бесполезную статистику заряженности девайсов.
Фича довольно-таки полезная: для эмуляторов рабочего стола можно показывать заряд батареи и статус заряда. Можно понижать качество анимаций если заряд батареи низкий.
В будущем браузер сможет получать практически всю инфрмацию о ПК: кол-во процессоров, температуру устройств, параметры сети www.w3.org/TR/system-info-api/
Вобщем все браузеры(не только хром ос) идут к тому, чтобы заменить оболочку ОС.
Фича довольно-таки полезная: для эмуляторов рабочего стола можно показывать заряд батареи и статус заряда. Можно понижать качество анимаций если заряд батареи низкий.
В будущем браузер сможет получать практически всю инфрмацию о ПК: кол-во процессоров, температуру устройств, параметры сети www.w3.org/TR/system-info-api/
Вобщем все браузеры(не только хром ос) идут к тому, чтобы заменить оболочку ОС.
Кстати, а если это UPS?
«Умные» UPS'ы вроде как прописываются в системе также как батарея ноута. Разве что оставшееся время от балды показывают, но статус зарядка/питание от сети/от аккумулятора показывают. а если упс «тупой» (только 220в на системник подает), то фигли с ним говорить? Просто негде!
Вот и я про то же. azproduction предложил определять, на ноуте ли идет работа или на десктопе, но что будет, если к десктопу подключен «умный» UPS? В стандарте W3 есть isExternal, но тот ли это атрибут?
Не очень меня радует перспектива такой открытости информации о моей системе. И ведь не отключишь так просто.
Почитал раздел «3. Security and Privacy Considerations» этого System Information API.
Что-то мне подсказывает что как всегда, если эта гадость все-таки появится в браузерах, то «отключалка» будет запрятана где-нибудь в неведомых дебрях джунглей about:config'а.
И надежно «выпилить шпиона» можно будет только при сборке с явным указанием --disable-system-info-api. А то, мне лично, совсем не греет душу наличие аттрибутов macAddress, ipAddress и прочего явного вмешательства в мою частную жизнь.
Что-то мне подсказывает что как всегда, если эта гадость все-таки появится в браузерах, то «отключалка» будет запрятана где-нибудь в неведомых дебрях джунглей about:config'а.
И надежно «выпилить шпиона» можно будет только при сборке с явным указанием --disable-system-info-api. А то, мне лично, совсем не греет душу наличие аттрибутов macAddress, ipAddress и прочего явного вмешательства в мою частную жизнь.
Оба свойства — только для чтения.
Возможность записи в navigator.battery.level была бы очень интересна… :)
Тогда даешь API для управления производительностью браузера, иначе большого смысла от API Battery не вижу(кроме уведомлений для юзера)… или я уже опаздал?
А чего мелочится? Весь /proc (или аналог) засунуть в navigator, типа:
/proc/cpuinfo → navigator.cpuinfo
/proc/meminfo → navigator.meminfo
Сразу будет ясно — имеет-ли смысл тяжелый алгоритм грузить, если процессор слабый.
/proc/cpuinfo → navigator.cpuinfo
/proc/meminfo → navigator.meminfo
Сразу будет ясно — имеет-ли смысл тяжелый алгоритм грузить, если процессор слабый.
Так процессор может быть и не слабый, но нагружен чем-то еще. Тут уж лучше произвести замер производительности на каком-то типовом куске и из него тогда понять чего дальше грузить. Да и в процессе работы можно корректировки вносить на основании замеров времени выполнения.
Вот у меня сейчас показывает частоту 800 МГц на каждом ядре, а может разогнаться при необходимости до 2700. Не решит ли ваш скрипт, что у меня машина слабая?
На сколько я помню, в cpuinfo показывается номинальная частота.
volch@home:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 18
model : 1
model name : AMD A4-3400 APU with Radeon(tm) HD Graphics
stepping : 0
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat npt lbrv svm_lock nrip_save pausefilter
bogomips : 5400.10
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
processor : 1
vendor_id : AuthenticAMD
cpu family : 18
model : 1
model name : AMD A4-3400 APU with Radeon(tm) HD Graphics
stepping : 0
cpu MHz : 2700.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat npt lbrv svm_lock nrip_save pausefilter
bogomips : 5399.54
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
volch@home:~$ cpufreq-info
cpufrequtils 007: cpufreq-info © Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 1000 ns.
hardware limits: 800 MHz - 2.70 GHz
available frequency steps: 2.70 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1.40 GHz, 1.10 GHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 2.70 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 2.20 GHz.
cpufreq stats: 2.70 GHz:54,02%, 2.40 GHz:2,00%, 2.20 GHz:1,97%, 2.00 GHz:2,22%, 1.80 GHz:5,24%, 1.40 GHz:4,29%, 1.10 GHz:4,52%, 800 MHz:25,75% (24491272)
analyzing CPU 1:
driver: powernow-k8
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 1000 ns.
hardware limits: 800 MHz - 2.70 GHz
available frequency steps: 2.70 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1.40 GHz, 1.10 GHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 2.70 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 2.70 GHz:53,77%, 2.40 GHz:1,91%, 2.20 GHz:1,82%, 2.00 GHz:2,05%, 1.80 GHz:4,94%, 1.40 GHz:3,99%, 1.10 GHz:4,36%, 800 MHz:27,17% (23696740)
volch@home:~$
> Оба свойства — только для чтения.
Жаль.
Жаль.
Извините, но Файрфокс что — особенный? Просто в других браузерах сие АПИ тоже будет доступно же.
В W3C окончательно выжили из ума
Согласен, совершенная чушь. Никакое веб-приложение не должен волновать уровень батареи. Если уж говорить об уменьшении количества запросов для обновления и прочей ерунды которая, якобы может увеличить время работы. то логичнее вводить режим экономии энергии, а не выносить это решение на уровень конкретного приложения.
Добавка акселерометра в мобильные браузеры, например, была использована в играх. Современны браузер — это платформа. А задача платформы — предоставить API. И пусть уже конкретное [веб]приложение пусть решает что с ним делать.
Юзкейсы бывают разные, может мне жизненно необходима работа веб-приложения в одной вкладке без всяких оптмизаций павера, а другое мне нужно только при работе от сети 220 вольт. Предлагаемые API gjpdjkz.n 'ne ghj,ktve htibnm? ysyt ceotcnde.obt — njkmrj hexrfvb/
Мне кажется, они идиоты. Приведите реальный юзкейс для этой штуки? Сообщить о том, что батарейка садится, и надо бы сохранить документы, вполне может операционная система (более того, это именно ее обязанность). И более того, непонятно, что, все разработчики прилоежний должны теперь утяжелять свое приложение кодом обработки этого события? Зачем?
Экономить батарейку таким образом вряд ли получится, современные движки рендеринга css3 с тенями, скруглениями и градиентами настолько тяжелы, что им ничем не поможешь.
Плюс, под альтернативными платформами усложняется реализация. В Линуксе веть нельзя вызвать функцию getBatteryLevel(), там надо мучаться с дбусами, демонами ACPI, менеджером устройств и прочими компонентами, любой из которых может отсутствовать, быть криво настроен или не работать.
Гораздо полезным событием было бы beforedisconnect/beforeoffline — вызываемое, например после нажатия кнопки засыпания (экран отключается, а у веб-приложения есть пара секунд, чтобы сообщить серверу, что сейчас связь будет разорвана), или при отключении сетевого интерфейса, или при сообщении от модема о том. что на счету заканчиваются деньги, в подобных случаях.
Экономить батарейку таким образом вряд ли получится, современные движки рендеринга css3 с тенями, скруглениями и градиентами настолько тяжелы, что им ничем не поможешь.
Плюс, под альтернативными платформами усложняется реализация. В Линуксе веть нельзя вызвать функцию getBatteryLevel(), там надо мучаться с дбусами, демонами ACPI, менеджером устройств и прочими компонентами, любой из которых может отсутствовать, быть криво настроен или не работать.
Гораздо полезным событием было бы beforedisconnect/beforeoffline — вызываемое, например после нажатия кнопки засыпания (экран отключается, а у веб-приложения есть пара секунд, чтобы сообщить серверу, что сейчас связь будет разорвана), или при отключении сетевого интерфейса, или при сообщении от модема о том. что на счету заканчиваются деньги, в подобных случаях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Возьми API, JavaScript; поди узнай скорей-ка, что в Файерфоксе нашем села батарейка!…