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

BFE>А как без перерисовки "нахрен всего" вы корректно сделаете ресайз? Думаете сейчас как-то иначе делается?
В нормальных приложениях перерисовка делается однократно, а не по нескольку раз, в стиле "ой, теперь мне нужен скролл бар, так что мы разошлём всем новые значения размеров; ой, теперь из-за скроллбара у нас перестало влазить по горизонтали, так что надо ещё один скроллбар; так, теперь у нас сползает сплиттер, потому что уже эту зону делать нельзя, поехали всё заново".

BFE>Стандартный прогресс бар действительно был ужасен поэтому нормальные разработчики им не пользовались.
А чем?
BFE>Ну не помню я такого. Отрисовка плохо работала только если памяти не хватало и начинался своппинг.
Значит, память плохая. Компиляция проекта на Дельфи была примерно втрое быстрее, если отключить вывод прогресса (окошко со счётчиком скомпилированных строк). Своп означал, что всё просто ложится навзничь — ну, то есть делаем Alt-tab в Word и ждём секунд 40, пока хоть что-то зашевелится.
А без свопа тормозила именно отрисовка.

BFE>Если у вас было достаточно оперативной памяти, то можно было включить кеширование оконных изображений и тогда загрузки на 100% не было.
Не было такого.

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

НС>>Не, DN тормозил, Нортон работал ОК, Волков летал.
S>DN может быть, да.

Тут показательней пример VC, который был немного беднее по функционалу, но пользовался большой популярностью прежде всего в силу того, что работал быстрее всех и занимал меньше памяти.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Не, DN тормозил, Нортон работал ОК, Волков летал.
S>>DN может быть, да.

НС>Тут показательней пример VC, который был немного беднее по функционалу, но пользовался большой популярностью прежде всего в силу того, что работал быстрее всех и занимал меньше памяти.

Мне помнится, в нашей компании пользовались Нортоном пятым (после третьего). Остальное как-то не прижилось. Что про DN говорили, что он тормозил, я помню, хотя не помню, чтобы я сам это видел. Как у DN копировщик был прикольно сделан, помню, а тормоза нет. Почему Волков Командер не прижился, не помню вообще, хотя помю, как кто-то его качал с BBS.

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

НС>>Тут показательней пример VC, который был немного беднее по функционалу, но пользовался большой популярностью прежде всего в силу того, что работал быстрее всех и занимал меньше памяти.

S>Мне помнится, в нашей компании пользовались Нортоном пятым (после третьего). Остальное как-то не прижилось. Что про DN говорили, что он тормозил, я помню, хотя не помню, чтобы я сам это видел. Как у DN копировщик был прикольно сделан, помню, а тормоза нет. Почему Волков Командер не прижился, не помню вообще, хотя помю, как кто-то его качал с BBS.

VC помещался на загрузочную дискету, а нортон — нет.

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

BFE>>А как без перерисовки "нахрен всего" вы корректно сделаете ресайз? Думаете сейчас как-то иначе делается?
S>В нормальных приложениях перерисовка делается однократно, а не по нескольку раз, в стиле "ой, теперь мне нужен скролл бар, так что мы разошлём всем новые значения размеров; ой, теперь из-за скроллбара у нас перестало влазить по горизонтали, так что надо ещё один скроллбар; так, теперь у нас сползает сплиттер, потому что уже эту зону делать нельзя, поехали всё заново".

Ну да. Но минимум один раз всё надо перерисовать.

BFE>>Стандартный прогресс бар действительно был ужасен поэтому нормальные разработчики им не пользовались.
S>А чем?

Сами рисовали.

BFE>>Ну не помню я такого. Отрисовка плохо работала только если памяти не хватало и начинался своппинг.
S>Значит, память плохая. Компиляция проекта на Дельфи была примерно втрое быстрее, если отключить вывод прогресса (окошко со счётчиком скомпилированных строк).
Дельфи я не больше 100 раз за жизнь использовал, наверное.

S> Своп означал, что всё просто ложится навзничь — ну, то есть делаем Alt-tab в Word и ждём секунд 40, пока хоть что-то зашевелится.
Не всегда. 40 секунд — это когда уже совсем мало памяти.

S>А без свопа тормозила именно отрисовка.
Были приложения в которых тормозила отрисовка, это те которые: обращались к диску за данными, пересчитывали области при масштабировании больших картинок для отрисовки (карты, схемы ....), переопределяли свою палитру для ограниченных 256 цветов (но этим мало кто заморачивался)

BFE>>Если у вас было достаточно оперативной памяти, то можно было включить кеширование оконных изображений и тогда загрузки на 100% не было.
S>Не было такого.
Было-было, только не все об этом знали.
В Windows вообще много чего есть о чём мало известно даже программистам:
— В Windows можно работать в разных аккаунтах и логиниться под одним не выходя из другого. Я не знаю почему, но у многих этот факт вызывает удивление.
— В Windows можно установить свой менеджер окон например с поддержкой нескольких десктопов.
— В Windows можно запускать графические приложения от имени и с правами других пользователей под своим аккаунтом.
— Windows можно установить на логический диск отличный от C (даже семёрку и десятку)
и т.д. и т.п..

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

BFE>- В Windows можно установить свой менеджер окон например с поддержкой нескольких десктопов.

Устанавливать свой менеджер окон тоже не нужно, всё уже давно встроено, только не выведено в UI. Но функции для создания и переключения десктопов были в винде уже очень-очень давно.

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

НС>>>Тут показательней пример VC, который был немного беднее по функционалу, но пользовался большой популярностью прежде всего в силу того, что работал быстрее всех и занимал меньше памяти.

S>>Мне помнится, в нашей компании пользовались Нортоном пятым (после третьего). Остальное как-то не прижилось. Что про DN говорили, что он тормозил, я помню, хотя не помню, чтобы я сам это видел. Как у DN копировщик был прикольно сделан, помню, а тормоза нет. Почему Волков Командер не прижился, не помню вообще, хотя помю, как кто-то его качал с BBS.

kgd>VC помещался на загрузочную дискету, а нортон — нет.

Смотря какой нортон и на какую дискету, наверное. Третий нортон, кажется, помещался везде, но я не уверен.

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

BFE>Ну да. Но минимум один раз всё надо перерисовать.
Один раз и даёт приемлемую скорость отрисовки.
Плюс — аккуратная инвалидация только той части окна, которая попадает под ресайз.
BFE>Сами рисовали.
Я бы не взялся. Смысла нет. Алгоритмические оптимизации дают гораздо более хороший результат — например, обновлять прогресс раз в 200мс, а не на каждый "шаг". Это экономит усилия на написание собственного прогресс бара, и гарантирует совместимость с пользовательскими темами.

BFE>Дельфи я не больше 100 раз за жизнь использовал, наверное.
Ну и что. Дело не в Delphi, а в производительности TextOut.
BFE>Не всегда. 40 секунд — это когда уже совсем мало памяти.
Дело не в объёме памяти, а в скорости диска.

BFE>Были приложения в которых тормозила отрисовка, это те которые: обращались к диску за данными, пересчитывали области при масштабировании больших картинок для отрисовки (карты, схемы ....), переопределяли свою палитру для ограниченных 256 цветов (но этим мало кто заморачивался)
Я вам объясняю простую вещь: в 90х годах (и начале 2000х) запросто тормозила именно отрисовка. Безо всякого обращения к диску и свопа.
Масштабирование больших картинок (карты, схемы) как раз работало обычно более-менее ок, т.к. там работает чистая математика, а алгоритмы писаны бывалыми людьми.

Плохо работали приложения, которые были написаны тяп-ляп, и делали слишком много перерисовок в единицу времени. Потому что GDI тормозила.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Когда началась гонка мегагерцев, в бордах, форумах, чатах хором ныли, что де никто нормально не пишет, все надеются на апгрейд.

НС>Во времена ХТ еще никакой гонки не было.

А так же не было никаких форумов, чатов, не было библиотеки MFC и тд. А я пишу именно про это.

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

I>>Софт на движке Turbo Vision по дефолту не умел этот фокус. Борландовские тулы кое как умели, а юзерский софт надо было учить таким чудесам. И особенностью этого Turbo Vision было неуемное потребление памяти, особенно плюсовой версии. Что бы побороть такое, товарищи придумали "оверлеи", предок нынешних ДЛЛ и своппинга.

L>И работало это все мгновенно.

Смотря что и в какое время

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

I>>Прошло всего 20-25 лет, и то время вдруг стало золотым веком

C>Да нет, не золотым веком. Вполне вероятно, что на том железе интерфейсы тормозили примерно так же, как и новые сейчас. Вот только сейчас железо мощнее раз так в 50-100, чем тогда.

Да не интерфейсы тормозили!

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

Ровно то же и сейчас — ты бОльшую часть сайтов даже не замечаешь, работают себе и работают. Но вдруг некоторые даже кнопку с тормозами рисуют. Что это значит ? Да то же самое, что это значило 20-30 лет назад — такие вот разработчики.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Довольно мгновенно, кстати говоря.

НС>Не, DN тормозил, Нортон работал ОК, Волков летал.

Ну вот, хоть кто-то помнит, что DN тормозил. У него был довольно навернутый UI — куча всяких прибамбасов. Многие даже не знали, что там столько всего есть.

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

S>Мне помнится, в нашей компании пользовались Нортоном пятым (после третьего). Остальное как-то не прижилось. Что про DN говорили, что он тормозил, я помню, хотя не помню, чтобы я сам это видел. Как у DN копировщик был прикольно сделан, помню, а тормоза нет. Почему Волков Командер не прижился, не помню вообще, хотя помю, как кто-то его качал с BBS.

У DN был гораздо требовательнее VC, который работал внятно даже на XT. DN мог упарываться на некоторых 486 типа 486SX-25. А вот DX2-66 уже не тормозил.

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

S>Плохо работали приложения, которые были написаны тяп-ляп, и делали слишком много перерисовок в единицу времени. Потому что GDI тормозила.

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

Здравствуйте, Ikemefula, Вы писали:
I>Плохо работали именно из за тяп-ляп, а не медленного GDI Даже с тормозным GDI находились решения — рисовали упрощенно, без наворотов. Но всегда находились умники, которые точно так же как и сейчас, ту же упрощенную кнопку рисовали с тормозами.
Ну вот то-то и оно: голый винапи был неудобен для рисования наворотов; а типовые сценарии были более-менее отрихтованы парнями из Редмонда.
MFC предлагала более быстрый способ выкопать себе яму: навертеть кучу динамического поведения. Способ был доступен даже тем разработчикам, кто не понимает принципов оптимизации. Имхо, рассуждения про "тормоза MFC" именно отсюда.

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

I>>Плохо работали именно из за тяп-ляп, а не медленного GDI Даже с тормозным GDI находились решения — рисовали упрощенно, без наворотов. Но всегда находились умники, которые точно так же как и сейчас, ту же упрощенную кнопку рисовали с тормозами.
S>Ну вот то-то и оно: голый винапи был неудобен для рисования наворотов; а типовые сценарии были более-менее отрихтованы парнями из Редмонда.
S>MFC предлагала более быстрый способ выкопать себе яму: навертеть кучу динамического поведения. Способ был доступен даже тем разработчикам, кто не понимает принципов оптимизации. Имхо, рассуждения про "тормоза MFC" именно отсюда.

Примерно так — в MFC писать было довольно легко. Чистый WinApi ввергал в ужас даже опытных MFC-разработчиков, когда им приходил проект на чистом Си

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

I>Ровно то же и сейчас — ты бОльшую часть сайтов даже не замечаешь, работают себе и работают. Но вдруг некоторые даже кнопку с тормозами рисуют. Что это значит ? Да то же самое, что это значило 20-30 лет назад — такие вот разработчики.

Прекрасно замечаю — они все тормозят, кроме редких исключений, которые почти не тормозят

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

C>>Кроме того, отрисовкой примитивов давно уже занимается видеокарта, так что разрешение имеет минимальое значение. Если только программист не настолько идиот, чтобы перерисовывать всё десятки раз.
Z>Я смотрю со своей колокольни. Qt/Widget до сих пор рендериться на CPU.

Угу, особенно на Android'е. Или на винде с ANGLE...

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

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

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

Z>>>Справедливости ради, тогда разрешения экрана были совсем другие.

C>>Прямо совсем?

Z>(3840 * 2160) / (640 * 480) = 27 раз увеличилось количество пикселей

Ага, тогда и проц был в одно ядро и целых 233МГц, или меньше. Когда пошли пеньки 2, то уже было 1027*768. Да и щас ширпотреб это FHD и 2K. 4K — редкость. А вот процы стали 10 раза мощнее только по частоте, не забываем что IPC вырос, а видео карты на порядки шустрее стали.

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

BFE>>Ну не помню я такого. Отрисовка плохо работала только если памяти не хватало и начинался своппинг.
S>Значит, память плохая. Компиляция проекта на Дельфи была примерно втрое быстрее, если отключить вывод прогресса (окошко со счётчиком скомпилированных строк). Своп означал, что всё просто ложится навзничь — ну, то есть делаем Alt-tab в Word и ждём секунд 40, пока хоть что-то зашевелится.
S>А без свопа тормозила именно отрисовка.

Ну среда Дельфи сама по себе ужасна. Если VS, развёрнутая на весь экран, вытесняла кого то в своп, то этот кто-то так и мог там сидеть долго, пока не понадобится (т.е. пока не свернёшь студию либо не переключишься). А вот при работе в Дельфях постоянно были видны нижележащие программы и рабочий стол, которые должны были отрисовываться. Поэтому своп не переставая шуршал.