Достать бы где ЭССЕ по этому поводу, мол, чего оно такое быстрое-то, а, ребят? Почему иксы ни в какое сравнение не ставятся? Может 1280 на 1024 винда моментально перерисовывает оттого, что каждый производитель видеоадаптера свои драйверы под нее пишет?
Так ведь иксы через сеть работают, даже на локальной машине. Это было актуально для безмозглых терминалов тех времён. А вот почему оно до сих пор работает через ж..., т.е. через сеть - это другой вопрос
Жульничество это. Быстрый GUI в WIN 3.11 - сам видел на П-2, когда надо было кое-что под старый комп проверить. А вот когда перешел с 98-го на 2000-й, тоже сначала удивлялся. А потом смотрю : приложения медленней работают. Стал разбираться : окошки в 2000-м "разворачиваются со свистом" , т.е. быстрее чем в 98-м. У юзера создается эффект быстроты. Для этого же сделали выезжающее меню "Программы". А на деле общее время - больше. Не верите - поставьте WIN 3.11 и увидите, что мы потеряли.
imho не корректно сравнивать GUI NT систем с 16битными версиями. у них и возможности разные. и от разрешения/глубины цвета оч много зависит. если отключить всякие сглаживания, затенения и прочие рюшечки, то работать будет быстрее, чем в 3.11, т.к. там аппаратное ускорение не используется.
Кто сказал, что оно быстрое? У меня в KDE стартовое меню открывается быстрее, чем в 2000. А вообще секрет скорее всего в драйверах.
valterg А потеряли ли? Там кое-где пару галочек поставить и будет все как всегда. Моментально и эффективно. А КДЕ да, тормоззит. Гном тоже торопится не шибко. В причинах не разбирался, так что скромно промолчу, потупив взор. С позиции юзера мне надо только чтобы эффективно все работало, поэтому размалеваная ХР меня пугает.
n0p аналогично, и тому же, раздражает , однако у нее есть классический стиль (по крайней мере пока ). а вот 3.1 с вордом 6.0а на к6/266 гонял было - летало все как пуля!
пункт №1 - гуя в XP нынче живет в ядре, а не в юзермоде - сделано для скорости. пункт №2 - гуя в XP оптимизирована под процессор - т.е. в гуевых либах отдельные блоки кода под процессор конкретный - схема используется практически такая же как для FPU - есть код эмуляции FPU который по прерыванию работает. И есть код работы с FPU - который работает через FPU. если FPU нет - включается эмуляция. В лелексе по умолчанию такого нет. пункт №3 - XFree - нынче работает не через сетку (если локально) а через сокеты. Почуствуйте разницу. А теперь касательно скорости - я когда последний раз на машинку ставил линукс, то все работало не очень быстро. Тогда KDE 3.2 только появилась её и поставил. Потом я потратил два дня на следующее - замена компилера и бинутилс на новые, которые поддерживают PIV процессор. А так же определение опций компилятора (имеется ввиду оптимизация + опции поддержки процессоров), с которыми система работала стабильно. В итоге получился набор опций, который включал к примеру такую вещь, как работа с векторами через SIMD. После этого я XFree и KDE а так же некоторые либы (libgif, libtiff, libjpeg и некоторые другие) перекомпилил с этими опциями. В итоге получил некоторый прирост производительности.... Небольшой.. 400 процентов всего. Собственно как результат скорость была сравнима с виндовой. Кстати. Касательно сравнения KDE и Windows UI - здесь есть некоторая разница. KDE - это C++ с собственной отрисовкой окон и контролов. А вот MSCOMCTL сделана на голом C - т.е. отрисовка контролов в винде сделана на С, исходя из того, что С более быстрый язык чем С++.
rst Эээээ... А как это может не быть FPU? На древний 386 ведь XP всё равно не поставить. Локальный сокет сродни именному пайпу? Вы это имеете в виду? Зато MFC, WTL и т.д. на C++.
Quantum - я привел аналогию FPU. Точно так же сейчас работает поддеркжка современных процессоров в ХР. Касательно сокетов - да. Сродни. Касательно MFС - он использует стандартные виндовые контролы, а не реализует свои. А в KDE именно свои реализуются посредством QT. QT в принципе является аналогом MFC, НО - QT забирается на более низкий уровень - отрисовку объектов. В MFC эта задача делегирована MSCOMCTL (кстати возможно в названии либы ошибаюсь, но суть та же) А насчет _полностью_ объектноориентированного интерфейса - милости прошу - VS.Net, HTML Dialogs - по скорости очень медленно.
rst А-а-а... Понял про FPU, а то я уж было испугался Пример с MFC я неудачно привёл, но есть же либы, которые сами всё рисуют, как в Борланде. Мне кажется, что дело всё-таки не в языке, а в компиляторе. GCC для C++ генерирует отстойный код, и не только в линуксе (я его в основном для PalmOS использую), а для ANSI C чуть лучше, но это всё из-за того, что GCC не дружит с оптимизацией. Java - ещё один расточительный хроник - нативный AWT чтоб нарисовать обычную кнопку 10 раз обратится к реестру, а о Swing я вообще лучше промолчу. Зато VC вполне грамотно оптимизирует C++ код и, если не злоупотреблять всякими виртуальными (короче, пустыми и ненужными) классами, try/catch'ами и т.д., то код будет прамо как в сишном варианте.
Quantum - вот поэтому я и говорю- оптимизация, оптимизация и ещё раз оптимизация unroll loops, omit stack pointers, -march=pentium4, sse -03 переменные в регистрах, использование FPU для переменных... и т.д. и т.п. В результате может быть код и будет отстойным, НО зато он будет работать быстро. Как я уже говорил - KDE начинает работать раза в 4 быстрее. Вообще.. кстати. надо бы поставить линух жене на ноутбук, заодно и потренируюсь
rst > А можно об этом подробнее? afaik единственныя компонент ядра виндоса, который может различаться на конкретном железе - HAL (причины к GUI отношения не имеют). Всё остальное одинаково, причём ядро (почти) не использует FPU/MMX. Косвенно об можно судить по размеру win32k.sys: 2K gold - 1 726 256 байт, 214 записей в таблице экспорта; XPSP2 - 1 836 032 байт, 225 записей в таблице экспорта. Пропорциональное увеличение размера кол-ву функций. Если бы в XP появился процессорозависимыё код, то win32k.sys бы заметно увеличился. "Оптимизацию" под процессор использует DirectX, там это вроде бы на уровне "есть mmx, нет mmx". Соответственно и GDI+ тоже. Что там в других юзермодных либах не знаю, но думаю мало что изменилось со времён NT. А вот перекомпилировать с нормальными ключами - да, это imho не мешало бы сделать и на виндосе
