Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна.
S>
S> <Здесь был Screenshot>
S> Жаль на шоте не видно что окошко дергают...

100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.

K_O>>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет.
S>Гм... Мне всегда было на самом деле интересно — чем отличается "уровень ядра" от остальных в плане производительности?

Само по себе, где именно рисовать не так уж и важно, алгоритм рисования должен быть примерно одинаков по производительности. Но, видишь ли, графические примитимы в конце концов рисует драйвер видеокарты, а драйвер работает в винде всегда в режиме ядра. А вот что уже играет огромную роль — так это количество переключений из Kernel Mode в User Mode и обратно. На Интеловской архитектуре такое переключение — очень затратная операция. Поэтому чем меньше таких переключений, тем лучше. Если графика реализована в User Mode, значит переключаться придется для рисования каждого примитива. А если графика реализована в Kernel Mode — это значит, что переключаться придется намного реже, в начале отрисовки сложного контрола и при возврате из функции рисования.

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Здравствуйте, Sheridan, Вы писали:

S>>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна.
S>>
S>> <Здесь был Screenshot>
S>> Жаль на шоте не видно что окошко дергают...

K_O>100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.

K_O>>>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет.
S>>Гм... Мне всегда было на самом деле интересно — чем отличается "уровень ядра" от остальных в плане производительности?

K_O>Само по себе, где именно рисовать не так уж и важно, алгоритм рисования должен быть примерно одинаков по производительности. Но, видишь ли, графические примитимы в конце концов рисует драйвер видеокарты, а драйвер работает в винде всегда в режиме ядра. А вот что уже играет огромную роль — так это количество переключений из Kernel Mode в User Mode и обратно. На Интеловской архитектуре такое переключение — очень затратная операция. Поэтому чем меньше таких переключений, тем лучше. Если графика реализована в User Mode, значит переключаться придется для рисования каждого примитива. А если графика реализована в Kernel Mode — это значит, что переключаться придется намного реже, в начале отрисовки сложного контрола и при возврате из функции рисования.

Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.

Здравствуйте, Denwer, Вы писали:

D>Ну я же предложил тебе сделать программу на QT которая будет рисоваться на Mac OS в стиле Win XP. Или наоборот на винде но в стиле MAC OS.
D>У них есть два типа стилей, это платфомро зависемый и независеймы. ВОт независеймый стиль они действительно рисую сами. Но ты можешь его не использовать. Вот цитата их их доки

D>

D>The QWindowsXPStyle class provides a Microsoft WindowsXP-like look and feel.
D>Warning: This style is only available on the Windows XP platform because it makes use of Windows XP's style engine.

D>Вот та DLL о которой я говорил как раз и есть style engine.

То, что на винде нет стиля Mac OS еще не говорит об использовании родных библиотек для рисования виджетов. Это говорит о том, что ребята сделать качественную поддержку стиля на другой платформе не смогли. Или это, в принципе, невозможно. Еще раз, посмотри исходники.

K_O>>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна.
D>Это ничего не доказывает. Просто более медленная работа. Напрмер если я в MFC программе при отрисовке сделаю цикл с 1000000 итерациями она тоже будет тормозозить, выходит MFC сама рисует контролы.

Разница лишь в том, что Qt-шная форма будет тормозить и в том случае, если я специально ничего затормаживать не буду.


K_O>>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет.
D>Винда все рисует на уровне ядра!!! Даже если ты сделаешь MoveTo(...) LineTo(...) — это рисуется в режиме ядра.

Не надо так нервничать, тебя все прекрасно слышат. Важен не факт нахождения в режиме ядра, а количество переключений. См. мой соседний ответ.

Здравствуйте, Denwer, Вы писали:

D>Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.

В моем эксперименте были получены другие данные — 70% времени кушал процесс с неподвижной формой, 30% — перетаскиваемый калькулятор.
Но дело не в этом. Когда я хочу создать качественное приложение с ГУИ мне не особо важно, какая именно часть Qt виновна в тормозах. Ясное дело, что тут и рисование и рассылка событий и много прочей ерунды. Речь ведь изначально шла о Qt в целом. Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Здравствуйте, Denwer, Вы писали:

D>>Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.

K_O>В моем эксперименте были получены другие данные — 70% времени кушал процесс с неподвижной формой, 30% — перетаскиваемый калькулятор.
K_O>Но дело не в этом. Когда я хочу создать качественное приложение с ГУИ мне не особо важно, какая именно часть Qt виновна в тормозах. Ясное дело, что тут и рисование и рассылка событий и много прочей ерунды. Речь ведь изначально шла о Qt в целом. Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.

А никто и не спорит что QT замедляет работу, но тогда уж выбирай либо ты рисуешь каждую форму на АПИ по 10 дней, либо рисуешь за 1 час но скорость работы гуя медленнее. Кстати я вот не слышал что бы кто то жаловался на скорость работы оперы(хотя я им не пользуюсь).

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Arioch2, Вы писали:

A>>Все что не написано на Oberon++ — в биореактор!!!!!!

S>Что такое оберон?

Это что-то такое из соседней ветке. Как критикуют — замкнутое само на себе.

И это было насчет утверждения, что нужно только два языка.

Д>>Кстати, как там RSDN@Linux поживает?
S>Дык вот начал кутэ учить,

А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах

Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites

D>Кстати я вот не слышал что бы кто то жаловался на скорость работы оперы(хотя я им не пользуюсь).

А ты уверен, что Опера/Win использет Qt ?
Тогда скажи, легко ли из qt/Win вызовы drag-n-drop как-то вынести наружу ?
За всю долгую жизнь не хватает мне в Opera/win переноса. Прям думается не попробовтаь ли написать переходник между X DnD и MS COM DnD

PS: Есть какие-то притормознутые места в ресайзах, на вскидку не помню. Что-то было.

Здравствуйте, Arioch2, Вы писали:

A>И это было насчет утверждения, что нужно только два языка.

Ладно — ладно... 3. Еще ассемблер для совсем уж низкого уровня...

Здравствуйте, Arioch2, Вы писали:

A>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах
A>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites

Верно понимаеш... Есть Qt — зачем дотнет?

A>>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах
A>>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites

S>Верно понимаеш... Есть Qt — зачем дотнет?


Дааа... а мне говорили, что OpenSource — это Bazaar. А тут такой Catherdral с инквизиторскими кострами....
А Beagle-то не знает

Здравствуйте, Arioch2, Вы писали:

A>>>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах
A>>>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites

S>>Верно понимаеш... Есть Qt — зачем дотнет?


A>Дааа... а мне говорили, что OpenSource — это Bazaar. А тут такой Catherdral с инквизиторскими кострами....
A>А Beagle-то не знает

Лучшее оно всегда враг хорошего...
Честно скажу — под виндами на шарпЕ программлю ибо нет инпрайзовской тормознутости билдера. В линухах жеж Qt самое то — и надеюсь со временем перейду в Qt и под виндами...
И вот что я вам скажу... Простота и функционал кутэ находится между mfc и winforms, но кутэ обходит их вместе взятых по кроссплатформенности

Здравствуйте, Kh_Oleg, Вы писали:

K_O>100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.


Спокойно себе ресайзил, не мельтешил... Прорисовка страдает...

Здравствуйте, Kh_Oleg, Вы писали:

> Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.
Тормознее, чем .NET WinForms ???
Сравнение RSDN@Home и Opera 8.5 явно не в пользу RSDN@Home. Все еще усугубляется тем, что Опера и HTML перерисовывает — и тормозов все равно намного меньше.

Здравствуйте, Сергей, Вы писали:

>> Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.
С>Тормознее, чем .NET WinForms ???
С>Сравнение RSDN@Home и Opera 8.5 явно не в пользу RSDN@Home. Все еще усугубляется тем, что Опера и HTML перерисовывает — и тормозов все равно намного меньше.

Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....

Здравствуйте, Сергей, Вы писали:

С>Здравствуйте, Kh_Oleg, Вы писали:

>> Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.
С>Тормознее, чем .NET WinForms ???
С>Сравнение RSDN@Home и Opera 8.5 явно не в пользу RSDN@Home. Все еще усугубляется тем, что Опера и HTML перерисовывает — и тормозов все равно намного меньше.

Не надо сравнивать слона с носорогом. Сравнивайте равноценные приложения. Взять хотя бы стандартный Блокнот, его аналог на Qt и его аналог на WinForms. А уже потом RSDN@Home и его же, на Qt...

Здравствуйте, Sergey J. A., Вы писали:

[..]

SJA>Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....

А на тормоза при ресайзе это как влияет?

Здравствуйте, Kh_Oleg, Вы писали:

[...]

K_O>Не надо сравнивать слона с носорогом. Сравнивайте равноценные приложения. Взять хотя бы стандартный Блокнот, его аналог на Qt и его аналог на WinForms. А уже потом RSDN@Home и его же, на Qt...

Сдается мне, Опера будет покруче и понавороченней, чем RSDN@Home в плане интерфейса. И переформатирование HTML страницы (RSDN.RU) при ресайзе — это тоже непростая операция. И при этом не шибко навроченное WinForms окошко тормозит сильнее.

Здравствуйте, Sergey J. A., Вы писали:

SJA>Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....

Чтото я не видел в коде чтобы он по ресайзу в базу лез...

С>Сдается мне, Опера будет покруче и понавороченней,

Спошу еще раз, здесь все уверены, что Opera/Win32 использует Qt ?
Учитывая, что opera/Win была всегда, а проект Opera/Magic появился в районе Opera 5.
И что, они сменили весь к тому времени наработанный GUI ?