Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2011-01-16 16:54:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Внезапные простые решения
     Когда-то давно, когда по поверхности планеты бегали велосирапторы, а на компьютерах "Ай-Би-эМ Пи-Си" стоял MS-DOS, программисты уже писали программы "с окошками" (и, подозреваю, у каждого компьютерщика тех времён найдётся самописная "оконная библиотечка"). Окошки создавались тривиально - сохранением и последующим восстановлением области экрана под окном, благо в текстовом режиме места она занимает мало.
     Потом появился графический интерфейс (например в виде Windows), и выяснилось что "картинку под окном" сохранять нельзя, ибо некуда (обычной памяти мало, видеопамяти - очень мало, помню все эти расчёты при покупке видюхи "если поставить 1024х768 то получится всего 256 цветов, а в 800х600 уже можно позволить себе 64k цветов"), и для окошек надо что-то придумать. И придумали, гениально простую вещь - содержимое окна не сохранять вообще, для восстановления - попросить приложение, которому принадлежит окно, "перерисоваться". Кстати, до меня только сейчас дошло, почему в win1.0 были запрещены перекрывающиеся окна: они просто ещё не умели их перерисовывать!

     Быстро шли годы, медленнее проходили десятилетия. Типичный объем компьютерной памяти вырос до нескольких гигабайт, видеопамять тоже росла как на дрожжах: меньше полугига сейчас уже наверное и не найти (а в полгига, если что, можно примерно 60 раз целиком уложить экран 1920х1200). Я когда-то удивлялся, зачем видеокарте памяти в разы больше, чем может понадобиться для вывода картинки, потом привык. Параллельно, на деньги любителей 3D игр, производители видюх развивали вроде-бы-больше-никуда-не-нужное 3D (я про него вспоминал разве что глядя очередную киношку "через оверлей", причём вспоминал только когда "оверлей" глючил). Сама операционная система 3D особо не пользовала, а окошки при показе так и перерисовывались приложениями: в XP все признаки перерисовки при переключении (вроде "белых окон", подтормаживания и перерисовки "не всего и не того") были в полный рост.

     А потом как-то внезапно до софтописателей дошло. Что сейчас уже можно каждому окну выделить собственную область видеопамяти - пусть себе там рисует по потребности, а когда нужно его показать - достаточно просто сделать эту область видимой средствами видеокарты!
     И получился интерфейс Windows Aero (впервые появившийся в Vista, если я не путаю - лично с вистой не работал, сразу перешёл на 7). И внезапно оказалось, что если все окошки в готовом виде хранятся в видеопамяти, а видеокарта позволяет с ними произвольно оперировать, многие вещи становятся легче, проще и удобнее. Показ окна становится настолько дешевым действием, что его можно делать по событию вида "навелись мышом куда надо" (убрали мышь - убрали окно), можно дёшево показать "превью" окна (при этом оно будет "живым и шевелящимся", поскольку это и есть настоящее окно, только уменьшенное средствами видеокарты), можно так же дёшево делать всякую мелкую анимацию при исчезновении/появлении, фишки вроде полупрозрачности - и всё это без нагрузки на процессор, ибо всё делается видеокартой в реальном времени. Даже в превьюшках, показываемых в переключалке alt/tab, окна "шевелятся" - и оно и понятно, это ж теперь очень дешевое (по расходу процессора) действие!

     А я-то до недавнего времени считал что 3D в видеокартах - "неизбежное зло, и для UI от него пользы никакой". А в win1.0 негров линчевали окна перекрываться не могли. А оно вон какой внезапно прогресс. :-)
     Кстати, любопытно - как оно сейчас во всяких юниксах типа линукса. С одной стороны - памяти раньше всем не хватало, а значит "во времена оные" как-то извращаться приходилось всем. С другой стороны - если я правильно понимаю идеологию xserver/xclient, просить приложение перерисовываться по каждому чиху может оказаться накладным, перерисовываться желательно xserver'у (но "окно" хранить не в виде дампа, конечно, а более компактно), что резко упрощает идеологически переход к "все окна лежат в реальной видеопамяти".
     Я лично с линуксом давно дел не имел, поэтому не в курсе. Кто скажет - там уже так же как в Aero? А они это первыми придумали, или микрософт?


(Добавить комментарий)


[info]ext_229571@lj
2011-01-16 11:01 (ссылка)
> И получился интерфейс Windows Aero

Ну вообще-то Compiz и получился, он был несколько ранее. А ещё ранее были 3D эффекты в MacOS X. Более того, будущий Wayland уже с самого начала разрабатывается с учётом того, что он будет плевать на перекрывающиеся окна, там главный — композитор.

(Ответить) (Ветвь дискуссии)


[info]ext_229571@lj
2011-01-16 11:11 (ссылка)
Да, а в классическом X Server окна перерисовывает клиент, тут ничего нового — есть специальное событие.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-16 11:15 (ссылка)
Но хотя бы в случае работы по сети это, надеюсь, хоть как-то оптимизировалось (попытками перерисовать локально, не дёргая клиента)?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_229571@lj
2011-01-16 11:17 (ссылка)
Да, конечно, картинки кэшировались пискмапами, шрифты там тоже… Но вообще протокол X11 не слишком оптимизирован под медленное соединение, он оптимизирован под тупые терминалы, без мощных процессоров. Другое дело протокол NX.

(Ответить) (Уровень выше)


[info]dibr@lj
2011-01-16 11:14 (ссылка)
> Ну вообще-то Compiz и получился, он был несколько ранее.

А, ну вот примерно это я и спрашивал - я не особо слежу за тем, что в мире Linux происходит, мне винды хватает :-)

> Более того, будущий Wayland уже с самого начала разрабатывается с учётом того, что он будет плевать на перекрывающиеся окна

Не очень понятно - учитывая, что перекрывающиеся окна побороли четверть века назад, сейчас это при разработке нужно не "учитывать", а "подразумевать" - где-то рядом с "графика будет не какая-нибудь, а цветная" и "будет поддерживаться мышь" :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_229571@lj
2011-01-16 11:16 (ссылка)
Идея не в этом. Там выкинут событие «перерисовать окно» за ненадобностью — всё окна всегда рисуют в свою собственную область, которая никогда не перекрывается, а потом композитор соединяет всё это в единую картину с перекрывающимися окнами, но приложения это волновать не должно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-16 11:24 (ссылка)
А. Это разумно, кстати - меньше геморроя разработчикам, меньше графических глюков...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_229571@lj
2011-01-16 11:32 (ссылка)
Дык! :)

(Ответить) (Уровень выше)

X11
(Анонимно)
2011-01-16 11:42 (ссылка)
Там было хитро. Сервер X Window (по-русски это терминал) предпринимал попытку сохранить кусочек экрана, если перекрывающее окно не большое. Если не получалось, то давал команду на перерисовку.
Это приводило к тому, что при закрытии, скажем, диалогового окна или его перетаскиванию по экрану очень часто перерисовка не требовалась, все обходилось внутренним BitBlt без всякой сети.

(Ответить)


[info]nil59@lj
2011-01-16 12:06 (ссылка)
в OSX - сразу было так, как в aero.

собственно - большая часть ламерских восторгов от маков как раз отсюда и проистекала...

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2011-01-16 12:34 (ссылка)
Эппл, вообще, молодцы - столько полезного напридумывали (или как минимум популяризовали). Жаль, в результате производители привыкли "бегать за эпплом": если эппл что-то сделал, значит "нам тоже нужно так же"...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nil59@lj
2011-01-16 13:00 (ссылка)
по моим ощущениям - до выхода эппла на большую арену другие производители вообще никуда не бегали, а тупо продавали нам продукты прошлого века.

(Ответить) (Уровень выше)

Чиста для справки
[info]mc6312@lj
2011-01-16 12:36 (ссылка)
Окна с буферизацией ввенде появились еще в Windows 2000. Достаточно было при вызове CreateWindowEx указать стиль WS_EX_LAYERED. У таких окон заодно можно регулировать прозрачность.
Причем это все работало достаточно шустро без всякой железной акселерации.
Из-за памятежручести рекомендовалось такие окна использовать для всякой мелочи вроде всплывающих сообщений, но на машинах начиная где-то с третьего пня с >128М памяти стало на самом деле уже пофиг.

(Ответить)


[info]gnom_virtuoz@lj
2011-01-16 16:45 (ссылка)
я не знаю как там с дела с windows aero и использованием видео памяти. у меня на буке всего то 8Мб памяти, compiz летает без тормозов, а эфекты в нем куда круче чем у aero. да, и compiz таки был раньше чем aero.

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2011-01-16 16:53 (ссылка)
Тут уже объяснили, что compiz был раньше, а эппл с его OSX - ещё раньше :-) Просто я за миром линукс не слежу, поэтому не очень в курсе.

Надо будет, кстати, из интереса поставить на какой-нибудь старый комп линукс с compiz - посмотреть, что такое "летает без тормозов" в данном случае... :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]gnom_virtuoz@lj
2011-01-16 17:45 (ссылка)
изкоробчатый компиз (что касаемо бубунты) только и умеет, что "резиновые окна" и "куб рабочих столов" ну и еще пару плюшек. для полного надо поставить пару пакетов и там уже можно рулить и конфигурять как душе угодно. А на счет быстродействия, тот же аеро требует для себя хорошей производительности, когда компиз как я говорил, на моей 8 метровой видюхе работает отлично. Немного может тормознуть когда включается эфект сгорания, большого окна развернутного на весь экран.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]demon_nn@lj
2011-01-17 10:33 (ссылка)
Угу, и вообще, на старых видюхах шейдерные эффекты, скажем так, неторопливые очень. Брызги воды у меня весь первый пень с GForce 5300 вытормаживали сильно. Так-же как и надписи огнем.

А вот различные деформации, вроде взрывающихся или изгибающихся окон, бегали на ура.\

2 Dibr: Дабы понять о чем речь ;)
http://www.youtube.com/watch?v=w-8kLhwMf1g
http://www.youtube.com/watch?v=vkuhVtqjYao

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-17 19:41 (ссылка)
Ну, это уже извращенство какое-то - так над окнами издеваться :-)
Хотя впечатляет, да :-)

(Ответить) (Уровень выше)


[info]ilya_314@lj
2011-01-17 17:53 (ссылка)
Эта приятная фича оконного движка, но парадигма разработки интерфейса все еще в прошлом. Программы по большей части обрабатывают WM_PAINT и должны заниматься всякой фигней. Хотя конечно в основном это возложено на библиотеки, но любой шаг в сторону - это куча проблем.

Но уже давно есть WPF (на нем кстати из крупного софта - например VS2010 написана) в котором описана сцена состоящая из разных слоев 2д и 3д, отрисовку всей этой кучи + анимацию делает движок и делает это настолько гладко (если векторные эффекты) насколько железо позволяет. Идеология как у flash, которую реализовали для десктопа, ну и silverlight - это подмножество.

(Ответить) (Ветвь дискуссии)


[info]ilya_314@lj
2011-01-17 17:59 (ссылка)
Вот тут выше писали про то что где-то уже сделали этот буфер перманентным и соответственно не нужно беспокоится что что-то там перетерли. Но это полумера, WPF в этом плане значительно продвинутее, тут вообще весь рендер делает движок, включая анимацию, масштабирование и прочее.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-17 19:38 (ссылка)
Главное чтобы это ещё и работало с приемлемой скоростью. Переход с 2Д на 3Д понятен - чего карточке простаивать, пусть интерфейс рисует - а карточки быстрые, и идеология получилось лучше чем раньше, поэтому получилось быстрее. Тут же - "дополнительные уровни абстракции", которые сами по себе не ускоряют, хотя и упрощают :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2011-01-18 05:44 (ссылка)
Работает это вполне нормально, технологии этой уже несколько лет и они уже успели всерьез заняться оптимизацией. Как-раз в начале 2010 года вместе с выходом VS2010 обновился WPF во многом благодаря самому VS2010, т.к. разработчики столкнулись с необходимостью доработок для такого крупного проекта. Еще MS Expression вроде на WPF написан.

А 3д в WPF - это дело дополнительное, его можно и не использовать, хотя движок для рендера сам использует ресурсы GPU на полную катушку.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-18 18:36 (ссылка)
3D я имел в виду в том смысле, что всё это легко реализуется поверх 3Д возможностей видеокарты - без них это будет грузить процессор и тормозить. А приложение да, никакого 3Д в явном виде может и не использовать...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2011-01-18 18:42 (ссылка)
Думаю не загорами то время, когда вообще без 3D ничего не будет. Вот теперь уже и к ARM-ам приклеивают GPU и к x86 процессорам.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-18 18:50 (ссылка)
Как всё-таки хорошо, что эту часть прогресса большей частью оплачивают "любители поиграть". Не было бы платежеспособных и массовых игрунов, было бы вместо "3Д" - именно что "GPU с функцией StretchBlt", медленное и недешёвое. А так - и недорого, и польза даже неигрунам есть...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2011-01-18 19:03 (ссылка)
Индустрия игр никогда особо не бедствовала и кстати оплачивают удовольствие теперь не только игроки на консолях и pc, теперь еще и на мобильниках и планшетах 3д попрет.

Ходят упорные слухи, что 3д в windows 8 будет как-то мощно задействовано в огранизации десктопа, что это будет новый шелл, возможно опциональный, как и aero. Поэтому не удивляйся, что в будущем придется network connections искать где-нибудь в 3д пространстве внутри какой-нибудь коробочки.

Как-то бродила в голове такая идея - а почему-бы не озаботится нормальной визуализацией железа в компьютере. Ну чтобы ты видел свой системный блок наполненный всеми компонентами, мог посмотреть куда и что воткнуто. Для этого нужно кроме самих моделей железок еще и некое описание связывания компонент. Надо будет производителям создавать модели своего оборудование с описанием расположения интерфейсов и индикаторов.

Кстати в Win7 появился сетевой протокол который позволяет опросить устройства и нарисовать граф топологии сети, вот только не знаю многими ли он поддерживается, думаю нет.

(Ответить) (Уровень выше)


[info]ilya_314@lj
2011-01-18 05:46 (ссылка)
С переходом основная проблема в разработчиках - очевидно, что если существует многолетняя разработка написаная на (QT/MFC/GDI...) то вот так запросто все выкинуть и переписывать на WPF мало кто решится. Вот и сам MS из старых продуктов только VS портировал.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2011-01-18 18:38 (ссылка)
Ну, постепенно - существующие интерфейсы "поверх" WPF реализуются, а постепенно появятся новые разработки уже только под WPF, и когда-нибудь вытеснят. Как, собственно, почти со всем в мире компьютеров и происходит - вон, наконец-то (почти) совсем отменили штатную возможность гонять дос-задачки в винде...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2011-01-18 18:52 (ссылка)
Вот кстати для разработки интерфейса приложений Windows Phone 7 можно использовать только Silverlight (по сути тот же WPF, но урезаный) и XNA (это managed библиотека для 3D игр). Причем интеграция элементов в систему меню идет по сути через шаблон, который задает поведение внутри некого предопределенного контрола. Хорошо то, что движок как и managed код переносятся и приложение по идее можно заставить потом работать и на планшете и на пк и даже в браузере, вобщем много чего можно сделать. Но managed - это внешняя вещь по отношению к WPF, в Windows можно все это и из C++ использовать.

(Ответить) (Уровень выше)