C>Видимо, вам по работе не приходится, например, решать задачи с "реактивным" выводом пары сотен элементов на страницу, когда в контексте каждого нужно вывести ещё топ 3 релевантных элемента из словаря в зависимости от параметров. И всё это так, чтобы на бюджетном сяоми не подвисало.
C>Охренительно сложная задача. Вывести пару сотен элементов, чтобы не тормозило. Ппц, до чего всё докатилось.
Здравствуйте, Sinclair, Вы писали:
S>Плохо работали приложения, которые были написаны тяп-ляп, и делали слишком много перерисовок в единицу времени. Потому что GDI тормозила.
Да не тормозила GDI. Она делала ровно то, что просили, столько раз, сколько просили. Она примитивна, а быть интеллектуальной ей не позволяли тогдашние вычислительные мощности.
Люди должны были таки читать мануалы и составлять алгоритмы правильно, а не и так сойдёт.
Здравствуйте, akasoft, Вы писали:
A>Да не тормозила GDI. Она делала ровно то, что просили, столько раз, сколько просили. Она примитивна, а быть интеллектуальной ей не позволяли тогдашние вычислительные мощности.
Непонятно. Неужели ваше определение "тормозить" означает "сделать не то, что просили", или "больше раз, чем просили"?
Общепринятое определение этого термина означает "работать медленно". То есть да, всё верно, GDI перерисовывало одну и ту же кнопку 25 раз, и занимало это две секунды.
Современные видеокарты могут перерисовать ту же кнопку 25 раз за 20мс, так что никто и не заметит этих повторных перерисовок. A>Люди должны были таки читать мануалы и составлять алгоритмы правильно, а не и так сойдёт.
Алгоритмы чего? Какие мануалы?
Напомню: мы говорим о том, тормозила ли MFC или нет — по сравнению с "голыми" WinAPI приложениями.
И есть мнение людей, не заставших девяностые годы в сознательном возрасте, что рисование на экране всегда было таким мгновенным, как сегодня, так что в MFC просто нечему тормозить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Непонятно. Неужели ваше определение "тормозить" означает "сделать не то, что просили", или "больше раз, чем просили"?
Я не согласен с тем, что "тормозит GDI", а не с тем, что "тормозит".
S>Общепринятое определение этого термина означает "работать медленно". То есть да, всё верно, GDI перерисовывало одну и ту же кнопку 25 раз, и занимало это две секунды.
Вот. Надо же учитывать, сколько времени займёт вызов рисования. И то, что сейчас железо работает быстрее не значит, что временем вызова надо пренебречь.
S>Современные видеокарты могут перерисовать ту же кнопку 25 раз за 20мс, так что никто и не заметит этих повторных перерисовок.
Но это будет такая же бессмысленная трата времени на рисование одного и того же. Надо составить алгоритм, чтобы рисовать надо было 1 раз.
S>Алгоритмы чего?
Свои алгоритмы рисования с помощью GDI.
S>Какие мануалы?
Мануалы по использованию GDI.
S>Напомню: мы говорим о том, тормозила ли MFC или нет — по сравнению с "голыми" WinAPI приложениями.
Ну, прости что влез, про MFC мне сказать нечего.
S>И есть мнение людей, не заставших девяностые годы в сознательном возрасте, что рисование на экране всегда было таким мгновенным, как сегодня, так что в MFC просто нечему тормозить.
Согласен. Производительность и её изменение для меня очевидна.
Моё замечание про то, что даже тогдашнюю медленную отрисовку можно было существенно замедлить, если неправильно понимать, как чего рисуется.
А сейчасшное быстродействие не повод не учитывать тайминги.
C>Видимо, вам по работе не приходится, например, решать задачи с "реактивным" выводом пары сотен элементов на страницу, когда в контексте каждого нужно вывести ещё топ 3 релевантных элемента из словаря в зависимости от параметров. И всё это так, чтобы на бюджетном сяоми не подвисало.
C>Охренительно сложная задача. Вывести пару сотен элементов, чтобы не тормозило. Ппц, до чего всё докатилось.
Главное-то НЕ ЭТО!
Постановка задачи другая:
"Вывести пару сотен элементов, КОТОРЫЕ НИКОМУ НАХЕР НЕ НУЖНЫ!"
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
CS>>На самом деле народ в Блумберге сильно напрягается с этим делом.
C>Обновлять весь текст 25 раз в секунду? Народ в Блумберге просто занимается фигней.
Ну как данные торогов меняются они и меняют. С электронными торгами там вообще все грустно.
В играх вообще весь экран отрисовывается с 60 FPS как минимум. GPU отрисовка однако.
C>Обновлять весь текст 25 раз в секунду? Народ в Блумберге просто занимается фигней.
Для ботов (выдача по API в каком-нибудь JSON) это имеет смысл. Только не на сайте СМИ, а на бирже, где официальные котировки, на которые можно ставить триггеры на покупку/продажу.
Здравствуйте, Sinclair, Вы писали:
S>Непонятно. Неужели ваше определение "тормозить" означает "сделать не то, что просили", или "больше раз, чем просили"? S>Общепринятое определение этого термина означает "работать медленно". То есть да, всё верно, GDI перерисовывало одну и ту же кнопку 25 раз, и занимало это две секунды.
GDI использовало графические ускорители.
Более того, ускорители под GDI впервые и появились.
Более того, 2D рисовалось в GDI быстрее, чем вывод 2D плоскости в 3D через нулевые Z-координаты, поэтому и появился Direct2D чуть позже, который был как минимум не медленней GDI.
А то, что на формах-диалогах люди забывали (или не были в курсе) как правильно установить атрибуты окна и контрола (соотв. WS_EX_CONTROLPARENT и DS_CONTROL) или как реагировать на WM_ERASEBKGND — так это вопрос к профессионализму. На всех углах ведь обсуждалось как сделать так, чтобы при ресайзе не перерисовывались все контролы...
S>И есть мнение людей, не заставших девяностые годы в сознательном возрасте, что рисование на экране всегда было таким мгновенным, как сегодня, так что в MFC просто нечему тормозить.
В MFC тормозил общий map, где хранилось отображение хендлов на объекты-окна.
Соотв., создавалось окно тоже дольше, т.к. при создании каждого окна (т.е. и каждого контрола) вешался хук и соотв. хендл добавлялся в этот map.
ATL/WTL тормозили уже меньше.
Еще источником тормозов была рефлексия сообщений контролам, для обеспечения ООП-подхода, т.е. путь обработки каждого сообщения удлинялся.
Ну и, после выхода очередного SDK, где добавили достаточно макросов для "типизированной" обработки сообщений, порой стало удобней писать на голом WinAPI, вместо MFC, особенно если не надо на своих формах хостить ActiveX-контролы.
Здравствуйте, vdimas, Вы писали:
v> Ну и, после выхода очередного SDK, где добавили достаточно макросов для "типизированной" обработки сообщений, порой стало удобней писать на голом WinAPI, вместо MFC, особенно если не надо на своих формах хостить ActiveX-контролы.
Это про WindowsX.h ?
Так он вроде ещё в Win3.1 был, или я ошибаюсь?
