Так было всегда — либо все делать более или менее честно и рендерить один кадр несколько минут, либо все упрощать, объединять, оптимизировать и тогда успевать рисовать за доли секунды. Но даже со всеми оптимизациями, Diablo 3 на макбуке с ретиной выдает в лучшем случае 25 кадров в секунду на максимальном разрешении.
Простите, я не заметил, как мы перешли с проблемы разработчика — «какой API лучше подходит для каких задач» на проблему пользователя — «кто посмел вместо меня нажать Пуск для начала работы».
Дефолтный API плох для мобильных устройств, где важно время работы от батарейки. Запустили и свернули торентокачалку — у всех остальных приложений будет тормозить интернет. Запустили и свернули игру — у всех остальных приложений будет доступно меньше процессорного времени и памяти.
Новый API следит, чтобы такого не случалось. Нужно скачать большой файл — для этого есть встроенный сервис, который будет анализировать режим питания, подключение к интернету и может приостановить загрузку, если устройство работает от батарейки и она скоро сядет или если интернет работает через 3g. Этот сервис сам управляет скоростью загрузки и делает еще много чего полезного. Неактивные приложения в WinRT могут саспендаться на жесткий диск, снижать потребление процессора до нуля и памяти до килобайта. При этом они могут все так же получать обновления через пуш нотификации.
Все эти фишечки WinRT с контролем батарейки, векторным интерфейсом и встроенными сервисами актуальны в основном для мобильных устройств. То, что они доступны в том числе и на десктопе — просто приятный бонус.
Зачем? Старый код как работал, так и работает. А если есть желание писать под WinRT, то перелапачивать придется не просто код, а саму концепцию приложения — как оно взаимодействует с пользователем и системой. Если это не сильверлайт или WPF приложение, то придется использовать совершенно другие встроенные контролы для интерфейса. Если в приложении используются тяжелые вычисления и фоновые сервисы, то придется крепко задуматься — а можно ли это завести под WinRT? Не будет многих знакомых API и появится куча новых. Портировать более или менее сложное приложение с Win32 на WinRT бессмысленно и сложно.
Способность помнить много несвязанных фактов говорит лишь о том, что у человека хорошая память. Способность оперировать этими фактами, находить что-то общее среди них, умение видеть систему, делать какие-то выводы, использовать их для решения проблем требует не столько памяти, сколько анализировать, обобщать, делать выводы. Учить человека думать куда полезнее, чем учить его только лишь запоминать факты.
Ключи все-таки ближе к сертификату. Имея ключ, можно создать транзакцию на перевод денег со своего кошелька на чужой. Не имея ключа транзакция будет невалидная и будет отвергнута системой, так как все узлы будут проверять этот сертификат. Подробнее тут.
Новый API следит, чтобы такого не случалось. Нужно скачать большой файл — для этого есть встроенный сервис, который будет анализировать режим питания, подключение к интернету и может приостановить загрузку, если устройство работает от батарейки и она скоро сядет или если интернет работает через 3g. Этот сервис сам управляет скоростью загрузки и делает еще много чего полезного. Неактивные приложения в WinRT могут саспендаться на жесткий диск, снижать потребление процессора до нуля и памяти до килобайта. При этом они могут все так же получать обновления через пуш нотификации.
Все эти фишечки WinRT с контролем батарейки, векторным интерфейсом и встроенными сервисами актуальны в основном для мобильных устройств. То, что они доступны в том числе и на десктопе — просто приятный бонус.