I>Для ускорения приходилось писать рендеринг на Си или асме, но тогда на экране шел "снег", тк видюха тупо не справлялась. Для устранения эффекта снега надо было отключать прерывания, но это, внезапно, значительно снижало скорость отрисовки. Уже здесь была двойная буфферизация. Половина приложения большей частью занималась низкоуровневой отрисовкой UI.
Это известный дефект оригинальных CGA (я еще и на Геркулесах видел)
Дело там было не в скорости, а в доступе к видеопамяти. Для преодоления надо было не запрещать прерывания (какой смысл?), а просто нюхать один из регистров CGA и писать в видеопамять на обратном ходу луча (любом)
Здравствуйте, B0FEE664, Вы писали:
I>>Тут не требуется военных скоростей. Аналогично тормозил UI на MFC. BFE>UI на MFC тормозил, только когда с диска данные поднимал.
Ну это смотря как написали Была целая куча прилаг которые просто тормозили, даже без диска.
Хороший механизм был обновлять UI. И почему то люди находили удобным совать туда тяжелую логику, да еще принудительно дергать это обновление
I>>Странно, сборки мусора не было, а находилось целая куча приложений, что нещадно тормозили. Как так ? BFE>На паре сотен элементов? Да неужели?
На гораздо меньшем количестве элементов. Пара сотен — это не любой САПР столько контролов показывать станет. Что там делалось — для меня загадка.
BFE>И что, значит, находилось целая куча приложений? Она куда-то делась или тормозить перестала?
Я не слежу за судьбой всего что мне только на глаза попадается
Здравствуйте, Sinclair, Вы писали:
BFE>>UI на MFC тормозил, только когда с диска данные поднимал. S>Нущаспрям. Это если тот, который в примерах — со статической раскладкой контролов. S>А если сделать всё по науке, резиновая форма с резиновыми контролами, сплиттерами и т.п. — то ресайз окна превращался в пинг-понг сообщениями. Многократная перерисовка нахрен всего, вот это вот всё.
А как без перерисовки "нахрен всего" вы корректно сделаете ресайз? Думаете сейчас как-то иначе делается?
S>Тем временем, помните стандартный прогресс бар в Win95? Знаете, почему он был сделан "квадратиками"? Потому что режим "сплошной полоской" по честному перерисовывал на каждый invalidate всю синюю часть. S>А самое зачипатое было то, что эти долбоклюи не учитывали пиксельное округление. Поэтому прогон прогресса от 0 до 10000 в цикле, который ничего больше не делал, можно было видеть глазом, причём чем ближе вправо, тем медленнее ползла полоска
Стандартный прогресс бар действительно был ужасен поэтому нормальные разработчики им не пользовались.
S>Честные виндовые контролы не умели никаких ресайзов, поэтому тормозить там было почти нечему. MFС помогала обрабатывать развесистую динамику, которая тогда реально могла машинку положить.
Ну не помню я такого. Отрисовка плохо работала только если памяти не хватало и начинался своппинг.
S>ЕМНИП, оригинальная девяностопятка перемещение окна делала как и win3.1 — инверсной рамочкой. Отпустил — перерисовалось.
Такое помню.
S>Когда вышла толи 98, то ли OSR2 мы наблюдали, как прыгает до 100% индикатор task manager при перетаскивании окошка мышой.
Если у вас было достаточно оперативной памяти, то можно было включить кеширование оконных изображений и тогда загрузки на 100% не было.
Даже сейчас, при современных скоростях, постоянная перерисовка при резайзе будет занимать от 50% до 100% загрузки одного ядра. Я не вижу в этом ничего удивительного, так как нужно пересчитывать цвет каждого пиксела окна. Если в эту отрисовку вклинивается выполнение сборки мусора, то всё тормозит.
Здравствуйте, Codealot, Вы писали:
C>>>Видимо, твои коллеги и до такого уровня не дотягивались. I>>Ты решил мне нахамить ?
C>Почему бы это?
Тебе виднее, почему ты мне хамишь.
I>>"ничего не вижу" как то неконструктивно. Не знаю, как это интерпретировать. Не то у тебя браузер допотопный, не то ты думаешь, что умеешь кликать, не то видишь, но боишься покликать
C>См пункт 1. Ты утверждаешь, что там есть какой-то необычайно крутой функционал — ты про него и рассказывай.
В этом приложении реализован именно реактивный UI — кликнул, в других местах сразу все поменялось. Контролов на этой страничке всего лишь несколько десятков.
Это упрощенная версия задачи "реактивно несколько сотен"
Здравствуйте, Ikemefula, Вы писали:
I>>>Тут не требуется военных скоростей. Аналогично тормозил UI на MFC. BFE>>UI на MFC тормозил, только когда с диска данные поднимал. I>Ну это смотря как написали Была целая куча прилаг которые просто тормозили, даже без диска. I>Хороший механизм был обновлять UI. И почему то люди находили удобным совать туда тяжелую логику, да еще принудительно дергать это обновление
Ну, конечно, можно было сделать тормознуто, а можно быстро. Это если сборки мусора нет. Если сборку мусора добавить, то быстро не получится.
I>>>Странно, сборки мусора не было, а находилось целая куча приложений, что нещадно тормозили. Как так ? BFE>>На паре сотен элементов? Да неужели? I>На гораздо меньшем количестве элементов. Пара сотен — это не любой САПР столько контролов показывать станет. Что там делалось — для меня загадка.
Ну о чём-же речь? Что за приложения-то?
BFE>>И что, значит, находилось целая куча приложений? Она куда-то делась или тормозить перестала? I>Я не слежу за судьбой всего что мне только на глаза попадается
Если запустить старое приложение, то можно сильно удивится его высокой скорости работы.
Здравствуйте, Sharowarsheg, Вы писали:
I>>Тем не менее это факт. Более того, было полно крику и воплей даже про софт на чистом Винапи, и даже на чисто Си, что тормозит или жрет память.
S>Но я ни разу не помню такого про DOS.
Надо вспомнить, как работал Volkov Commander, Dos Navigator, Norton и прочие "оболочки". Перед запуском другой софтины они частично выгружали себя из памяти, а позже вгружали сами себя вновь.
Софт на движке Turbo Vision по дефолту не умел этот фокус. Борландовские тулы кое как умели, а юзерский софт надо было учить таким чудесам. И особенностью этого Turbo Vision было неуемное потребление памяти, особенно плюсовой версии. Что бы побороть такое, товарищи придумали "оверлеи", предок нынешних ДЛЛ и своппинга.
Если софтина требовала не менее 512кб памяти, то её просто так не запустишь, откуда попало. А потому было модно выносить саму ДОС и драйвера в верхние адреса памяти, что бы сэкономить память в основном блоке.
Здравствуйте, xarcass, Вы писали:
I>>Для ускорения приходилось писать рендеринг на Си или асме, но тогда на экране шел "снег", тк видюха тупо не справлялась. Для устранения эффекта снега надо было отключать прерывания, но это, внезапно, значительно снижало скорость отрисовки. Уже здесь была двойная буфферизация. Половина приложения большей частью занималась низкоуровневой отрисовкой UI.
X>Это известный дефект оригинальных CGA (я еще и на Геркулесах видел) X>Дело там было не в скорости, а в доступе к видеопамяти. Для преодоления надо было не запрещать прерывания (какой смысл?), а просто нюхать один из регистров CGA и писать в видеопамять на обратном ходу луча (любом)
Прерывания надо было запрещать, т.к. обработчики таймера и прочих вещей могли встревать невовремя. Заполнение всего экрана это довольно трудоемкая операция по тем временам.
Здравствуйте, B0FEE664, Вы писали:
I>>Хороший механизм был обновлять UI. И почему то люди находили удобным совать туда тяжелую логику, да еще принудительно дергать это обновление
BFE>Ну, конечно, можно было сделать тормознуто, а можно быстро. Это если сборки мусора нет. Если сборку мусора добавить, то быстро не получится.
Не могу с этим согласиться. У меня получалось делать внятный UI и на C++, и на .Net. При чем это был САПР, всегда нужно было отрисовывать вагон всего, и кастомные контролы, и визуализацию сети(граф).
Отрисовка графа начинала тормозить, когда количество элементов превосходилось тысяч 10 на одном скрине, что мягко говоря, не самый частый кейс. В примитивах это гораздо больше.
Узкое место в отрисовке был GDI, GDI+, а вовсе не GC. GC становился проблемой в вычислениях на больших объемах данных. Но и это было решаемо.
Зато товарищ один ухитрился сделать деревянный список на несколько десятков элеентов настолько тормозным, что клик проходил за секунды и даже десятки секунд. Обычный WinForms. Под капотом его списка — наколеночный табличный процессор, триггеры, пошаговая модель вычислений, цикличные обходы и прочая кунсткамера.
Или выпадающее меню на MFC, которое съедало все 100% если глубина вложенности 3 и больше, элементв несколько десятков и все это раскрыто на экране. Чел не нашел ничего лучше, как рисовать всё в WM_PAINT и форсить это дело несколько раз в секунду.
BFE>>>На паре сотен элементов? Да неужели? I>>На гораздо меньшем количестве элементов. Пара сотен — это не любой САПР столько контролов показывать станет. Что там делалось — для меня загадка. BFE>Ну о чём-же речь? Что за приложения-то?
Да редакторы, утилиты всякие — картинки, иконки, mp3-теги, качалки и тд.
I>>Я не слежу за судьбой всего что мне только на глаза попадается
BFE>Если запустить старое приложение, то можно сильно удивится его высокой скорости работы.
Сегодня — да. А в те времена точно так же были вопли на форумах, что де то и это тормозит да ест память.
Здравствуйте, Ikemefula, Вы писали:
I>>>Тем не менее это факт. Более того, было полно крику и воплей даже про софт на чистом Винапи, и даже на чисто Си, что тормозит или жрет память.
S>>Но я ни разу не помню такого про DOS.
I> Надо вспомнить, как работал Volkov Commander, Dos Navigator, Norton и прочие "оболочки". Перед запуском другой софтины они частично выгружали себя из памяти, а позже вгружали сами себя вновь.
Довольно мгновенно, кстати говоря.
I>Софт на движке Turbo Vision по дефолту не умел этот фокус. Борландовские тулы кое как умели, а юзерский софт надо было учить таким чудесам. И особенностью этого Turbo Vision было неуемное потребление памяти, особенно плюсовой версии. Что бы побороть такое, товарищи придумали "оверлеи", предок нынешних ДЛЛ и своппинга.
Да, но это всё равно было мгновенно.
I>Если софтина требовала не менее 512кб памяти, то её просто так не запустишь, откуда попало.
Ну если не запустишь, то не запустишь; но если уж запустил, то работало.
Здравствуйте, Ikemefula, Вы писали:
I>Тебе виднее, почему ты мне хамишь.
Видимо, потому что ты сильно борзеешь
Так где ссылки на посты 15-летней давности про то, как тормозит MFC?
I>В этом приложении реализован именно реактивный UI — кликнул, в других местах сразу все поменялось.
Здравствуйте, Sharowarsheg, Вы писали:
S>>>Но я ни разу не помню такого про DOS.
I>> Надо вспомнить, как работал Volkov Commander, Dos Navigator, Norton и прочие "оболочки". Перед запуском другой софтины они частично выгружали себя из памяти, а позже вгружали сами себя вновь.
S>Довольно мгновенно, кстати говоря.
Нисколько — порядка нескольких секунд до или после в зависимости от скорости накопителя
I>>Софт на движке Turbo Vision по дефолту не умел этот фокус. Борландовские тулы кое как умели, а юзерский софт надо было учить таким чудесам. И особенностью этого Turbo Vision было неуемное потребление памяти, особенно плюсовой версии. Что бы побороть такое, товарищи придумали "оверлеи", предок нынешних ДЛЛ и своппинга.
S>Да, но это всё равно было мгновенно.
Ни разу не мгновенно, особенно если хдд не было, надо было грузиться с дискеты. Гы-гы — переставляешь дискету, где у тебя оболочка, нажимаешь кнопку и ждешь пока он подгрузится.
I>>Если софтина требовала не менее 512кб памяти, то её просто так не запустишь, откуда попало.
S>Ну если не запустишь, то не запустишь; но если уж запустил, то работало.
Здравствуйте, Sharowarsheg, Вы писали:
S>Ладно, у меня другие воспоминания, начиная с XT. Правда, надо признать, без винтов мне не довелось поработать.
Когда началась гонка мегагерцев, в бордах, форумах, чатах хором ныли, что де никто нормально не пишет, все надеются на апгрейд.
Прошло всего 20-25 лет, и то время вдруг стало золотым веком
Даже совсем недавно рсдн был полон такого нытья. А тут уже вон как — жээс тормозит.
Ктото же читал файлы в Idle на мфц А чо, классный же механизм!
Здравствуйте, Ikemefula, Вы писали:
I>Когда началась гонка мегагерцев, в бордах, форумах, чатах хором ныли, что де никто нормально не пишет, все надеются на апгрейд.
И никаких доказательств опять не будет. Всё пустозвонишь и пустозвонишь.
I>Прошло всего 20-25 лет, и то время вдруг стало золотым веком
Да нет, не золотым веком. Вполне вероятно, что на том железе интерфейсы тормозили примерно так же, как и новые сейчас. Вот только сейчас железо мощнее раз так в 50-100, чем тогда.
Здравствуйте, Ikemefula, Вы писали:
I>Когда началась гонка мегагерцев, в бордах, форумах, чатах хором ныли, что де никто нормально не пишет, все надеются на апгрейд.
Во времена ХТ еще никакой гонки не было.
I>Прошло всего 20-25 лет,
Здравствуйте, Codealot, Вы писали:
C>Да нет, не золотым веком. Вполне вероятно, что на том железе интерфейсы тормозили примерно так же, как и новые сейчас. Вот только сейчас железо мощнее раз так в 50-100, чем тогда.
Здравствуйте, Ikemefula, Вы писали:
I> Надо вспомнить, как работал Volkov Commander, Dos Navigator, Norton и прочие "оболочки". Перед запуском другой софтины они частично выгружали себя из памяти, а позже вгружали сами себя вновь. I>Софт на движке Turbo Vision по дефолту не умел этот фокус. Борландовские тулы кое как умели, а юзерский софт надо было учить таким чудесам. И особенностью этого Turbo Vision было неуемное потребление памяти, особенно плюсовой версии. Что бы побороть такое, товарищи придумали "оверлеи", предок нынешних ДЛЛ и своппинга.
Была целая куча прилаг которые просто тормозили, даже без диска.
