Только это первый такой пример в отношении MS, причем, они существенно поменяли API операционной системы, и на уровне ядра нововведений немало, а вот у Apple от версии к версии изменения больше эволюционные.
Хотя в общем-то похоже, что MS «идет к успеху», пытаясь повторять путь Apple в таких моментах как магазин приложений, зарезанная обратная совместимость и сокращенный цикл выпуска новых версий ОС с платными обновлениями
Apple нигде не оперирует понятием HD, у меня в свое время был (не один) 15-дюймовый «виндоноут» с разрешением 1280x..., т.ч. для меня 1440x900 — высокое разрешение.
Глянец я видел, это не он. Ни одного отражения от лампочек, чисто матовый экран.
Если Apple такого пленками без потери яркости добивается, то пожалуйста.
Эйр куплен официально, без переклеек и доработок, из первых рук.
Не видел ведь не значит, что их не существовало ;)
У меня Macbook Pro 2010-го года, 15 дюймов, 1600x1050, матовый (антибликовый). Это не FullHD, конечно, но опции в AppStore звучали как high-resolution и anti-glare. Каждая долларов по 200.
У жены Macbook Air 2011 года, 13 дюймов, 1440x900, матовый. Для 13 дюймов вполне себе высокое разрешение ;)
Note: «высокое разрешение» (aka high-resolution) и high-definition (aka FulHD, 1920x1080) — разные вещи, если что. Особенно с точки зрения Apple, которая, по-моему, вообще не оперирует термином HD.
Значит, убрали.
У нас модель MC965RS/A — 13-дюйомвая с матовым (aka anti-glare) экраном, только что специально сходил, глянул, убедился.
Куплена 30.01.2012 (проверил по истории заказов).
Я что-то полазил, там теперь вообще нет опции anti-glare. У них что, теперь все экраны глянцевые?
Да не нужно особо :)
Было два интерфейса Reader/Writer, у обоих методы типа Seek и т.п.
Назывались одинаково.
Если делать Storage с обоими интерфейсами и независимыми курсорами на чтение/запись, на стандартном C++ без бубна не обойтись.
Мы тупо переименовали методы с совпадающими сигнатурами.
А так я сам смотрел и на RSDN спрашивал — делаются redirect-прослойки или в случае MSVC можно использовать ключевое слово __interface вместо абстрактного класса.
Старые «прошки» — какого года?
У меня 2010-го года high-resolution (1600 x 1050) anti-glare — вполне ок, если бы не выгоревшая по периметру матрица.
На новых ретинах народ на выгорание за год активного использования начал жаловаться. Не все, но многие.
У нас в организации в 2010-м году было куплено 5 MacBook Pro, из них 4 — с SSD, один — с обычным HDD.
Угадайте, сколько SSD накрылось медным тазиком за 3 года?
Правильный ответ — 4.
Жив только мой MacBook Pro с HDD 500GB, но при этом «выгоревший» по периметру экран (high-resolution anti-glare) очень даже «доставляет». Желтого цвета прямоугольник по периметру, в нижних углах текст плохо читается.
Ну и о том, что бывает глючная DRAM, я впервые узнал именно из опыта общения с этим MacBook. Брендовую планку за 200 у.е. пришлось менять на Kingston за 40 у.е., чтобы не везти ноут назад в country of origin.
P.S. При всем при этом народ у нас продолжает их любить и покупать, т.к.:
1) Тачпад!
2) Время работы от батарейки!
3) Удобный корпус
4) Контора платит
Я думаю о major-обновлении, как о навязанном мне существенном неудобстве.
На рабочий MacBook Pro 2010-го года пришлось ставить 10.8, потому что XCode 4.2 не устанавливался на 10.6, которая меня полностью устраивала.
С MS до недавнего времени существенно проще было. По крайней мере циклы жизни их продуктов (были) заметно больше, чем у Apple, а SP — бесплатны.
Да, я могу назвать как минимум одно: подмешивание интерфейсов.
История из жизни :)
Я тут недавно столкнулся с проблемой, когда пытался так «подмешивать» интерфейсы. Командой составили пару интерфейсов, в которых присутствовали методы с одинаковыми именами и сигнатурами.
По задумке предполагалось, что эти методы могут вести себя по-разному в объекте, реализующем оба интерфейса одновременно, в зависимости от того, через какой интерфейс к нему обращаются.
Т.е., грубо говоря, хотели реализовать вызовы вида:
Object::Interface1.Method() и Object::Interface2.Method() с различным поведением.
Выяснилось, что по стандарту так делать нельзя.
Есть несколько вариантов обойти это ограничение, но наследование перестает быть чисто абстрактным («интерфейсным»).
Или становится непереносимым, если использовать ключевое слово __interface в MSVC.
Ну вообще-то говорят, что техника Apple устаревает в момент покупки ;)
Все major-обновления ОС за денежку идут, если что. Небольшую, но все же…
Если бы МС начал за сервис-паки деньги требовать, его бы съели с потрохами.
Device-dependent.
Уменьшение задержки исключительно на совести вендора.
В Android существует цепочка, от которой не избавиться: Hardware Driver (OSS, ALSA, etc.) -> HAL (driver-independent wrapper) -> binder (android rpc) -> AudioFlinger (AudioRecord, AudioTrack)
Над флингером еще «пользовательские» классы сидят, которые тоже могут вносить задержку. Cнизить задержку до одного маленького буфера, как в iOS, невозможно, не вытащив прямые callback-и хотя бы с уровня HAL. Идеально было бы вообще настраивать драйвер под конкретные нужды (уменьшать размер буфера для real-time приложений).
ОЕМ-ы обычно не заморачиваются и ставят буферы побольше, потому что передаются через rpc они в программных потоках, а не в прерываниях, если где-то не успеть передать — услышите треск и прочие артефакты.
Ксатати, я еще в версии 2.2 видел относительно небольшие (60-80 мс) задержки у некоторых устройств HTC, «запиленных» под VoIP, но это было скорее исключением, и, кажется, нехило кушало ЦП.
Хм… В коммент не вчитывался, в статье — терминалы.
Но на самом деле неоднократно видел банкоматы, которые, кажется, не имеют постоянной связи:
1) безбожно тупят, хотя ПО на них такое же, как на «шустрых» товарищах
2) могут выдать «нет связи с банком, попробуйте позднее».
Либо ПО у них кривое и при отсутствии связи не сообщает об этом заранее, до того, как пользователь начал работать с ними, либо все-таки они «дозваниваются».
1. Ну, даже приведенная Вами цитата описывает другое «сглаживание» :)
Это ближе к межкадровой фильтрации.
2. Ну, на звуковом сигнале Вы его не уберете усреднением, там все-таки получается НЧ-фильтр, характеристика которого зависит от длины.
Для звука усреднение применяется, как я отписался, для оценки его характеристик, например, мощности, среднего уровня, пик-фактора и т.п.
А вот белый шум обычно убирают Винеровской фильтрацией. Причем, желательно с адаптивными коэффициентами.
На видеоизображении — да, там просто принято считать, что высокочастотные сигналы — шумовые. Хотя для некоторых видов изображения это и не вполне корректно (песок, листва и т.п.), в целом работает, особенно, если не увлекаться.
Ну, тогда стоило вообще отказаться от введения в математику и сразу переходить к практике :)
Т.е. рассказывать в духе: надо убрать неравномерность сигнала (усреднить) — делаем так. И без всяких спектров и пр.
В любом случае такие статьи полезны, потому что поддерживают интерес к области.
Далеко не многие вообще задумываются, что они в действительности делают, применяя различные преобразования к сигналам.
Хамить и не собирался, кстати, извините :)
Но вот пытаться меня «осекать», применяя столь странную терминологию и настолько некорректно построенные фразы, что смысл их теряется в облаках, пожалуйста, больше не надо.
Хотя в общем-то похоже, что MS «идет к успеху», пытаясь повторять путь Apple в таких моментах как магазин приложений, зарезанная обратная совместимость и сокращенный цикл выпуска новых версий ОС с платными обновлениями
Если Apple такого пленками без потери яркости добивается, то пожалуйста.
Эйр куплен официально, без переклеек и доработок, из первых рук.
У меня Macbook Pro 2010-го года, 15 дюймов, 1600x1050, матовый (антибликовый). Это не FullHD, конечно, но опции в AppStore звучали как high-resolution и anti-glare. Каждая долларов по 200.
У жены Macbook Air 2011 года, 13 дюймов, 1440x900, матовый. Для 13 дюймов вполне себе высокое разрешение ;)
Note: «высокое разрешение» (aka high-resolution) и high-definition (aka FulHD, 1920x1080) — разные вещи, если что. Особенно с точки зрения Apple, которая, по-моему, вообще не оперирует термином HD.
У нас модель MC965RS/A — 13-дюйомвая с матовым (aka anti-glare) экраном, только что специально сходил, глянул, убедился.
Куплена 30.01.2012 (проверил по истории заказов).
Я что-то полазил, там теперь вообще нет опции anti-glare. У них что, теперь все экраны глянцевые?
Было два интерфейса Reader/Writer, у обоих методы типа Seek и т.п.
Назывались одинаково.
Если делать Storage с обоими интерфейсами и независимыми курсорами на чтение/запись, на стандартном C++ без бубна не обойтись.
Мы тупо переименовали методы с совпадающими сигнатурами.
А так я сам смотрел и на RSDN спрашивал — делаются redirect-прослойки или в случае MSVC можно использовать ключевое слово __interface вместо абстрактного класса.
У меня 2010-го года high-resolution (1600 x 1050) anti-glare — вполне ок, если бы не выгоревшая по периметру матрица.
На новых ретинах народ на выгорание за год активного использования начал жаловаться. Не все, но многие.
Жене по крайней мере я такой покупал в 2011-м году. Или что-то изменилось?
Угадайте, сколько SSD накрылось медным тазиком за 3 года?
Правильный ответ — 4.
Жив только мой MacBook Pro с HDD 500GB, но при этом «выгоревший» по периметру экран (high-resolution anti-glare) очень даже «доставляет». Желтого цвета прямоугольник по периметру, в нижних углах текст плохо читается.
Ну и о том, что бывает глючная DRAM, я впервые узнал именно из опыта общения с этим MacBook. Брендовую планку за 200 у.е. пришлось менять на Kingston за 40 у.е., чтобы не везти ноут назад в country of origin.
P.S. При всем при этом народ у нас продолжает их любить и покупать, т.к.:
1) Тачпад!
2) Время работы от батарейки!
3) Удобный корпус
4) Контора платит
На рабочий MacBook Pro 2010-го года пришлось ставить 10.8, потому что XCode 4.2 не устанавливался на 10.6, которая меня полностью устраивала.
С MS до недавнего времени существенно проще было. По крайней мере циклы жизни их продуктов
(были)заметно больше, чем у Apple, а SP — бесплатны.N.B. Интересно, надо было © поставить к «устареванию в момент покупки», чтобы от фанатиков оградиться или где?
История из жизни :)
Я тут недавно столкнулся с проблемой, когда пытался так «подмешивать» интерфейсы. Командой составили пару интерфейсов, в которых присутствовали методы с одинаковыми именами и сигнатурами.
По задумке предполагалось, что эти методы могут вести себя по-разному в объекте, реализующем оба интерфейса одновременно, в зависимости от того, через какой интерфейс к нему обращаются.
Т.е., грубо говоря, хотели реализовать вызовы вида:
Object::Interface1.Method() и Object::Interface2.Method() с различным поведением.
Выяснилось, что по стандарту так делать нельзя.
Есть несколько вариантов обойти это ограничение, но наследование перестает быть чисто абстрактным («интерфейсным»).
Или становится непереносимым, если использовать ключевое слово __interface в MSVC.
Все major-обновления ОС за денежку идут, если что. Небольшую, но все же…
Если бы МС начал за сервис-паки деньги требовать, его бы съели с потрохами.
Уменьшение задержки исключительно на совести вендора.
В Android существует цепочка, от которой не избавиться: Hardware Driver (OSS, ALSA, etc.) -> HAL (driver-independent wrapper) -> binder (android rpc) -> AudioFlinger (AudioRecord, AudioTrack)
Над флингером еще «пользовательские» классы сидят, которые тоже могут вносить задержку. Cнизить задержку до одного маленького буфера, как в iOS, невозможно, не вытащив прямые callback-и хотя бы с уровня HAL. Идеально было бы вообще настраивать драйвер под конкретные нужды (уменьшать размер буфера для real-time приложений).
ОЕМ-ы обычно не заморачиваются и ставят буферы побольше, потому что передаются через rpc они в программных потоках, а не в прерываниях, если где-то не успеть передать — услышите треск и прочие артефакты.
Ксатати, я еще в версии 2.2 видел относительно небольшие (60-80 мс) задержки у некоторых устройств HTC, «запиленных» под VoIP, но это было скорее исключением, и, кажется, нехило кушало ЦП.
Но на самом деле неоднократно видел банкоматы, которые, кажется, не имеют постоянной связи:
1) безбожно тупят, хотя ПО на них такое же, как на «шустрых» товарищах
2) могут выдать «нет связи с банком, попробуйте позднее».
Либо ПО у них кривое и при отсутствии связи не сообщает об этом заранее, до того, как пользователь начал работать с ними, либо все-таки они «дозваниваются».
Это ближе к межкадровой фильтрации.
2. Ну, на звуковом сигнале Вы его не уберете усреднением, там все-таки получается НЧ-фильтр, характеристика которого зависит от длины.
Для звука усреднение применяется, как я отписался, для оценки его характеристик, например, мощности, среднего уровня, пик-фактора и т.п.
А вот белый шум обычно убирают Винеровской фильтрацией. Причем, желательно с адаптивными коэффициентами.
На видеоизображении — да, там просто принято считать, что высокочастотные сигналы — шумовые. Хотя для некоторых видов изображения это и не вполне корректно (песок, листва и т.п.), в целом работает, особенно, если не увлекаться.
Т.е. рассказывать в духе: надо убрать неравномерность сигнала (усреднить) — делаем так. И без всяких спектров и пр.
В любом случае такие статьи полезны, потому что поддерживают интерес к области.
Далеко не многие вообще задумываются, что они в действительности делают, применяя различные преобразования к сигналам.
Но вот пытаться меня «осекать», применяя столь странную терминологию и настолько некорректно построенные фразы, что смысл их теряется в облаках, пожалуйста, больше не надо.
Или продолжите путать «теплое с мягким»?