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

C>>Нет, они заменяются линкером при запуске, так что оверхеда не больше, чем при обычном вызове функции.
K>Но инлайна не будет. О чём товарищ выше и сокрушался.
Можно добавить аннотации на функции, которые чуть выше критичных инлайновых.

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

V>Запросто. Вот уже есть модель, второй частью работы является подбор материалов, т.е. текстур.
V>Бродишь по интернет-магазинам, качаешь текстурки их кафельных плиток, или обоев, или паркета/ламината и т.д., назначаешь различным поверхностям эти текстурки, смотришь что там получается. Это ж творческий процесс... ))

Тут лучше холст и краски тогда уж. Это вообще не инженерная работа.

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

K>Если реализовать его как сервис ОС, то думается мне, что МС с Интелом договорятся. Тем более, что это будет объективно выгодно обеим сторонам.

Да это явно уже виляния и отмазки пошли. Типа теория уже есть, заведомо правильная, теперь надо придумать для нее фактов.

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

НС>>Ну ок, в 90 вышла 3.0. По прежнему смешно.
N>И давно уже шла разработка NT, проги уже были.

Вот вот. Зарелизенный и продающийся i386, причем ровно тот, который и стал популярным, значит, недостаточно кошерен, зато разработка NT шла, дооо. И пофик что 3.1 вышла в 93, притом пользоваться ей было невозможно, а первая относительно рабочая версия была 3.51 образца 95.
Когда есть такая хорошая теория, факты можно и подстрогать, верно?

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

НС>>>Ну ок, в 90 вышла 3.0. По прежнему смешно.
N>>И давно уже шла разработка NT, проги уже были.
НС>Вот вот. Зарелизенный и продающийся i386, причем ровно тот, который и стал популярным, значит, недостаточно кошерен, зато разработка NT шла, дооо. И пофик что 3.1 вышла в 93, притом пользоваться ей было невозможно, а первая относительно рабочая версия была 3.51 образца 95.
НС>Когда есть такая хорошая теория, факты можно и подстрогать, верно?

Ты "забыл", что это ты придумал нелепое ограничение "начинаем с 1.0, потому что она тот же год, что i386". И после этого успешно борешься с ветряными мельницами, когда тебе говорят, что так "подстрогать" нельзя.
Ну, успехов в этом нелёгком деле, но без меня.

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

V>>>Вот именно что. Если бы AMD не навредила, то была бы сейчас архитектура IA64 в мейнстриме.
N>>Не была бы. Даже сейчас это сочетание хренового процессора и хреновых компиляторов.
V>Дык, это не мейнстрим, т.е. основные деньги и усилия индустрии не там.

В режиме альтернативной истории можно много чего обосновать. Но я считаю, что IA64 никакие вложения не помогли бы. Слишком уж оно шизанутое.

N>>Народ бы просто ушёл на что-то другое
V>А не было куда уходить.
N>>альтернативы были и активно использовались (как Apple на PowerPC)
V>Это даже не смешно.
V>1. На тот момент OSX технологически была в слишком глубокой ж-пе.
V>2. До поколения PowerPC G5 там было не о чем даже разговаривать — они годились только на игровые приставки и банковские терминалы.
V>И когда стало понятно, что G5 (где ввели 64-битную архитектуру)

RS64 это уже 1997-й. После Alpha, но задолго до IA64. G5 — точнее, PowerPC 970 — это 2002. Да, они долго шли. Тут уже я впаду в альтернативную историю, но думаю, что при несбитом спросе они бы заткнули все проблемы, вышли на нормальную цену, скорость и качество. Ну, может, годом позже — это не так фатально.

N>>конкуренты дышали в затылок и готовы были отнять всю базу.
V>На тот момент конкуренту Windows не было.

Я про процессоры, а не OS. Да, мародёрство остатков Alpha замедлило это. Но не сильно, потому что тот факт, что вышел общий заказ на 64-битность, видели все неленивые.

N>>AMD их спасла.
V>Ни в одном из мест. Винду и основные проги (офис, SQL-сервак) под Итаниум были переделаны и те первоначально работали быстрее, чем в архитектуре IA32.

Ойвэй. С чем сравнивали-то? С P-IV? Ну да, тогда ещё можно было что-то выгадать. Но с нормальными исполнениями — сомневаюсь. А чем дальше, тем больше разрыв усиливался, и дело не просто во вложениях.

V> Этого было достаточно для начала переезда. А там чем дальше, тем было бы быстрее.

V>AMD нас всех не спасла, а наказала.
V>Эта чёртова x86 архитектура — это ж позор всей индустрии.
V>И он теперь очень надолго.

В плане сохранения основных проблем x86 — я полностью согласен. Так бездарно прозевать все возможности улучшения ещё надо уметь.
В плане выбора альтернатив — я согласен на условное принятие многих, но никак не IA64.

V>Собсно, я не вижу способов избавиться от этого позора усилиями железячников, т.е. преодолеть эту инерционность.
V>Спасение должно было придти со стороны софта — как обсуждали байт-код здесь.
V>Скорее всего так и будет в итоге.

Ну проблемы этого подхода давно известны. Что-то я пока не видел унификации SIMD на уровне байткода.

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

V>А зачем стандартные?
А затем что 99.99% софта пользовалось стандартными.

V>До этого DirectDraw уже много лет был объявлен как deprecated, хотя прекрасно работал все годы.
Его просто не развивали.

N>>До этого делать гуй поверх DirectDraw означало делать закат солнца вручную, рисуя все контролы самому.
V>Во-первых, не так уж и самому. Можно прямо через системные АПИ рисовать части контролов (DrawFrameControl), подавая как параметр HDC.
А смысл? Это тот же GDI, но часто ещё и медленнее.

V>Можно более конкретный вопрос?
V>Т.е., в случае DirectDraw получаешь HDC у DirectDraw-поверхности, затем делаешь такие же точно вызовы для рисования
А нахрена тогда с DD surface заморачиваться вообще? Зови сразу GDI напрямую.

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

V>Что мешало скачать доку по RDP и банально заглянуть в неё?
V>https://msdn.microsoft.com/en-us/library/cc240445.aspx

Ты сам то эти доки читал?
Например вот этот:
https://msdn.microsoft.com/en-us/library/cc241537.aspx

The Remote Desktop Protocol: GDI Acceleration Extension aims to reduce the bandwidth associated with graphics remoting by encoding the drawing operations that produce an image instead of encoding the actual image.

V>Раздел "Slow Path" RDP-протокола совместим с T.128 до сих пор, кста.
Угу, поддержка легаси и всё такое.

V>В общем, смешно слушать рассуждения от тех, кто страшно далёк от темы и питается слухами/мифами.
Да, мне читать что ты пишешь и правда смешно.

V>Ты так и не понял, похоже, что это практически одно и то же.
Пойди по своим же ссылкам и прочитай наконец что там написано про весь RDP, а не только какой то сабсет RDP RFX, про который ты тут поёшь.

V>В RDP экран бъется на квадратики и передаётся (прямо как в потоковом видео перед кодированием).
Нет, там всё гораздо сложнее. С посылкой как битмапов, апдейтов к ним, так и примитивов отрисовки и прочей логической дельты + приличное и довольно умное кэширование всего на клиенте.
Именно поэтому он такой эффективный.

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

V>Значит, ты ОЧЕНЬ давно пользовался этим софтом. В лучшем случае в начале/середине 2000-х. ))
Ты много видел 34" моников в середине 2000х?

V>Запросто. Вот уже есть модель, второй частью работы является подбор материалов, т.е. текстур.
V>Бродишь по интернет-магазинам, качаешь текстурки их кафельных плиток, или обоев, или паркета/ламината и т.д., назначаешь различным поверхностям эти текстурки, смотришь что там получается. Это ж творческий процесс... ))
Пардон, но это довольно таки примитивный софт, который может бегать на самом планшете. RDP для него не нужен.

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

S>Почему сразу гиг?
Гиг на самом деле это ещё мало.

S> А только hotpath оптимизировать нельзя?
Чем больше scope тем потенциально лучше можно найти оптимальное решение.

S> А делать это итеративно (тут, наверное, уже все сложнее)?
Каждая итерация жрёт ресурсы просто сама по себе.

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

CC>>Wut?
K>Подумай своей головой, а не транслируй догмы, и ты поймёшь всё сам.
Звучит помпезно, но хотелось бы таки увидеть твоё объяснение.

CC>>Допустим возьмём С. Куда уже проще?
K>Ну дык он и переносим с минимальными проблемами.
Это сильно зависит от того, что мы делаем.

K> По крайней мере в своей "статической" части, которая не опирается на сервисы ОС.
Если задача просто перенести — да, но если надо ещё и получить максимум производительности на новой платформе то уже может понадобиться перепланировать алгоритмы и структуры данных.

K>у меня один codebase работал на МКшках Cortex-M0+, M3, M4 и M7
Я правильно понимаю что у них в общем то одна архитектура?

K>В реальности CISC-процы чудовищно неэффективны, т.к. в любой момент времени бОльшая часть его блоков простаивает. И даже суперскалярность с гипертредингом не спасает.
K>Сейчас такие есть только в мире ARM
Почему тогда по производительности лучшие ARM еле еле дотягивают до Core M семейства?

K>А ты подумай и сам ответь на свой вопрос.
Мне интересно твоё мнение. Своё мне уже известно.

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

IID>Уже взлетело. Как-то. С каким-то подобием PGO и onfly рекомпиляцией уже скомпилированных кусков. JIT-ы в последних андроидах.
Там жеж вроде как не JIT а compile-on-install, не?

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

K>Оно не просто буксует — оно встало колом и никуда не движется. Или ты из тех, кто считает 7-gen i7 новой архитектурой по сравнению с 6-gen i7?
Тебе шашечки или ехать?
Работает быстрее. А какая там внутри неонка — да до лампочки. Предсказуемость поведения следующего поколения куда более ценно.

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

I>Растр ни при чем. Растром в браузере можно рисовать не хуже чем в нативном виндовском апи.

Хуже. Проблема в том что спецификация <canvas> требует чтобы рисовалось в bitmap. Соответственно там CPU rendering.

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

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

IID>>Уже взлетело. Как-то. С каким-то подобием PGO и onfly рекомпиляцией уже скомпилированных кусков. JIT-ы в последних андроидах.
CC>Там жеж вроде как не JIT а compile-on-install, не?

Да, неправильно выразился. Имел в виду ART Runtime c AOT.
Не так давно этот рантайм научился перекомпилировать байткод в Native кусками, благодаря накопленной статистике.

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

V>>Запросто. Вот уже есть модель, второй частью работы является подбор материалов, т.е. текстур.
V>>Бродишь по интернет-магазинам, качаешь текстурки их кафельных плиток, или обоев, или паркета/ламината и т.д., назначаешь различным поверхностям эти текстурки, смотришь что там получается. Это ж творческий процесс... ))
Ops>Тут лучше холст и краски тогда уж.

Чего? )))
Это сколько вариантов в час можно перепробовать на холсте?


Ops>Это вообще не инженерная работа.

Разумеется, это дизайнерская работа.
Но сейчас это всё делается в одних и тех же программах.
Уже очень давно нет никакой "грани" между дизайнерскими и инженерными программами в строительстве, есть разный набор плагинов. ))
Включи все нужные плагины в проект и будешь делать там от разводки теплотрассы под домом, до выбора цвета рамки для фото над телевизором. ))
В общем, это всё известно уже очень давно... просто вас тут сразу трое коллег, упорно рассуждающих с позиций начала-середины 2000-х.

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

V>Чего? )))
V>Это сколько вариантов в час можно перепробовать на холсте?

Зачем перебор? Рисуй свои образы.

V>Разумеется, это дизайнерская работа.

Только большая часть работы на компе — это отнюдь не креатифф: бухгалтерия, документы, АСУ всякие. А рисование и музыка — это так, факультатив.

V>В общем, это всё известно уже очень давно... просто вас тут сразу трое коллег, упорно рассуждающих с позиций начала-середины 2000-х.

Точно. Не соответствуют моде

Автор: a.v.v
Дата: 07.06.17

.

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

N>Указанный тобой getDC() у surface это только начиная с Windows 7, то есть зверски поздно. До этого делать гуй поверх DirectDraw означало делать закат солнца вручную, рисуя все контролы самому. Или у тебя есть магический ход для более ранних версий?
Ну вообще-то, это было возможно.

См.: IDIRECTDRAWSURFACE7::GetDC() — https://msdn.microsoft.com/en-us/library/windows/desktop/gg426195(v=vs.85).aspx

Я точно помню, что и в более ранних DirectX можно было рисовать через GDI. Но оно было криво до невозможности всё, так как в Win98 оно автоматически блокировало поверхность, что вызывало взятие WIN16MUTEX. Т.е. любой вызов чего-то, кроме GDI-функций был чреват жёстким зависанием из-за не-реэнтерабельности API. Потому оно использовалось разве что для вывода текста.

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

V>>В D2D полностью аналогично, разве что идентификаторы участников чуть другие.
CS>Ох, ну нет конечно... там только слово Direct общее, а так парадигмы совсем разные.
CS>DirectDraw это про заброс bitmaps в видео память.

Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.


CS>Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).

GCI+ — вообще не по теме. Это юзверская либа поверх GDI. А GDI — это драйверная технология.
GDI так же имел возможность размещать битмапы в видеопамяти.
В общем, ты сейчас вообще переврал всё что можно. ))
Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).

Просто нельзя было узнать — вытеснили нафик этот битмап из видеопамяти в обычную, или оно еще там. А в случае DD можно явно запросить метод IsLost.


CS>Direct2D же...
CS>ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.

Опять мимо.
ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.


CS>Вызов ID2D1RenderTarget::DrawLine например это выполнение tessellation того отрезка с заданной stroke т.е. генерация вектора треугольников. А уж этот вектор треугольников отправляется на GPU для рисования.

Ох, мать... А какая нафик разница-то?

На момент выхода DirectDraw уже в обычном HDC давным давно применялось аппаратное ускорение на GPU, а значит, на GPU шли точно такие же данные в аналогичных сценариях в обoих случаях.

Повторюсь — там всей разницы (в твоём сценарии) в том, что DIB-битмапы в случае HDC живут в обычной памяти и их натягивание на картинку дороговато. Ну так умные люди пользовали DDB-битмапы в видеопамяти.


CS>Как ты видишь DirectDraw и Direct2D это принципиально разные вещи.

Они-то разные, ес-но. Но только не там, где ты описываешь. И уж не для тех целей, что ты описываешь.


CS>В условиях high-dpi monitors DirectDraw (bitmap на стороне CPU) это вообще не опция.

Пфф....
Показываю в три движения:

HDC wdc = GetDC(myHwnd);
HDC cdc = CreatecompatibleDC(wdc,...);
HBITMAP hbm = CreatecompatibleBitmap(wdc, ...);   // создание экранного буфера в видеопамяти 
SelectObject(cdc, hbm);                           // установили ему GDI-рисовалку
IDirectDrawSurface7 * dxSurface = NULL;
HRESULT rc = GetSurfaceFromDC(cdc, &dxSurface);    // получили для него же DirectDraw-рисовалку

Вот прямо с этого места делай с этим битмапом что хочешь.
Хоть через GDI, хоть через IDirectDrawSurface.
Не забудь только освободить, когда не нужен станет. )

Или можно было сделать наоборот — явно создать объект IDirectDrawSurface7 нужных размеров, у того попросить DC, а у того — приаттаченный битмап к нему.

Действительно принципиальное отличие IDirectDrawSurface от DC вовсе не BitBlt (оно, считай, идентичное в обоих случаях и выполняется аппаратно, если возможно), отличия (а) в режиме приаттаченных к друг другу поверхностей — стандартный цикл рисования в заднем буфере из цепочки со сменой текущего отображаемого буфера (Flip), а так же можно было синхронизировать этот Flip с обратным ходом развёртки.
Еще в DD появилась поддержка оверлеев и их Z-ордера (б).

Обе операции позволяли резко удешевить BitBlt, вернее, позволяли вовсе без неё обходиться — в первом случае для полноэкранного, во втором случае для оконного режима. У меня на одном из старых компов в конторе был забавный глюк — полноэкранное видео шло прекрасно, а даже в небольшом окошке тормозило. А рядом такой же точно комп, только чуть другая видюха — там не тормозило ни в одном из режимов. Очевидно, что некий GetDeviceCaps давал разные ответы насчёт оверлея ))

Кароч, собсно для для этих двух основных отличий DirectDraw и создали.


CS>Условно: для отрисовки флага республики Крым на полный экран в DirectDraw ты рисуешь bitmap в CPU и пересылаешь его/её в видео память.

ИМХО, я дал достаточно вводной инфы, чтобы любой коллега смог разбраться далее самостоятельно при желании.


CS>В Direct2D же это три вызова ID2D1RenderTarget::FillRect что выливается в посылку координат шести треугольников (+ три brush) в GPU.

Тоже неверно. В Direct2D на каждый четырёхугольник посылается ровно 4 вершины ))
Причем, неважно по какому типу PrimitiveType:
— triangle strip
— triangle fan
— quads

Последние два способа в случае четырёхугольника идентичны (обход вершин по часовой или против часовой), а первый способ требует нарисовать букву Z при обходе вершин четырёхугольника.

И да. Никакие Brush не надо. Каждой вершине присваивается свой цвет. Либо всем вершинам присваивается одинаковый цвет (до посылки примитива задаётся контекст операции). Дополнительно к каждой вершине может цепляться координата битмапа.

Точно так же происходит в случае GDI при использовании аппаратного ускорения, т.е. аккурат от момента выхода Windows 98, т.е. последние лет 20. ))


CS>Разница очевидна, нет?

Эмм...
Это если не знать, а потом еще и забыть.


V>>В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.
CS>Ну можно наверное frame buffer условно обозвать DirectDraw. Но очень условно.

Разумеется, очень и очень условно, бо нельзя на самом деле. ))
Аналогом "OpenGL Frame Buffer" надо называть "DirectDraw Surface", ес-но.


CS>Аналог же Direct2D в OpenGL... Ну вот скажем NanoVG это самое близкое по смыслу...

NanoVG — пакость редкостная, криворукая и вообще по шее за такое давать надо.
Настолько неплохая там идея (стыренная из GDI) и настолько кривая реализация, что аж обидно.
Что даже кривейший убогий SFML смотрится лучше.
Ты бы эта, посмотрел бы на досуге исходник NanoVG и ужаснулся.
Я бы долго пинал автора ногами, чесслово. ))
Двойная интерпретация внутреннего кодирования примитивов, да еще под каждый вшивый маленький блок при кодировании и раскодировании автор выделяет память из кучи и тут же освобождает. Это студенческая поделка низкого кач-ва.


CS>Image: screenshot-01.png

Не надо мне этим убожеством размахивать, я наизусть его знаю.
У меня своё чуть поинтересней есть для OpenGL. ))

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

CC> Ты сам то эти доки читал?

В отличие от тебя? — ес-но.
Я даже поток этот принимал.


CC>Например вот этот:
CC>https://msdn.microsoft.com/en-us/library/cc241537.aspx
CC>

CC>The Remote Desktop Protocol: GDI Acceleration Extension aims to reduce the bandwidth associated with graphics remoting by encoding the drawing operations that produce an image instead of encoding the actual image.

Осталось тебе узнать, в каком году появились эти "GDI Acceleration Extension", и насколько они использовались в случае double buffer drawing, — мы же с этого зацепились, верно? Или ты всерьёз понадеялся попытаться убежать таким незамысловатым образом? ))


V>>Раздел "Slow Path" RDP-протокола совместим с T.128 до сих пор, кста.
CC>Угу, поддержка легаси и всё такое.

Дык, RDP долгие годы и был тем самым T.128, как они купили его не помню уже у кого.


V>>В общем, смешно слушать рассуждения от тех, кто страшно далёк от темы и питается слухами/мифами.
CC>Да, мне читать что ты пишешь и правда смешно.

Ну это нервный смех.
Ты умудрился сесть в лужу вообще по каждой теме, которую обсуждали.

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


V>>Ты так и не понял, похоже, что это практически одно и то же.
CC>Пойди по своим же ссылкам и прочитай наконец что там написано про весь RDP, а не только какой то сабсет RDP RFX, про который ты тут поёшь.

А вот фиг тебе. ))
Не имея даже базовых представлений об организации иерархии capabilites в RDP или как принимаются решения при передаче инфы, ты просто продолжаешь тут позориться, вот и всё.
"весь RDP"... а-а-а-а-а

Чтобы какой-то битмап был перегнан на клиента, его надо интенсивно использовать много раз. Вот как раз участки кисти передаются квадратиками 8x8 чаще всего. А когда в "стандартной" процедуре double buffer прямо в обработчике WM_PAINT создаётся временный compatible DC, compatible bitmap, на них что-то рисуется и затем скидывается в экранный DC через BitBlt, и тут же этот битмап грохается (и так на каждый рисуемый контрол), то дудки вам с маком, а не GDI Acceleration Extension.

Тем более, что в 99% случаев после прорисовки контрола никаких изменений в нём не происходит (если попиксельно сравнивать) и слать обновления смысла нет.


V>>В RDP экран бъется на квадратики и передаётся (прямо как в потоковом видео перед кодированием).
CC>Нет, там всё гораздо сложнее.

Нет именно так в 99.9% случаев. ))
Остальное ничтожно и относится к таким приложениям, которых уже со времён обретения популярности RDP уже и не осталось.


CC>С посылкой как битмапов

Агащазз...

Я почему и высмеивал этот беспощадный полёт фантазии, бо при таком раскладе придётся предварительно перегонять по сетке все загруженные в видеопамять битмапы. Разумеется, никто в здравом уме так не делает. Сначала надо принять решение, что битмап стоит, таки, перегнать.

Даже Nine-Grid-Bitmap — это был такой специальный подвыверт, который активно использовался для прорисовки темы WinXP через uxtheme.
Но если ты не рисовал через uxtheme — всё пропало, полетели квадратики или в лучшем случае у тебя будет "ускорение" заливки прямоугольника сплошным цветом. )) (там в сжатом виде как бы не меньше объем информации был vs кодировка всяких GDI-команд, ы-ы-ы)

Ты же даже не то, что саму доку не открывал, ты даже следующий абзац не прочёл за цитируемым тобой же:

For example, instead of sending the bitmap image of a filled rectangle from server to client, an order to render a rectangle at coordinate (X, Y) with a given width, height, and fill color is sent to the client. The client then executes the drawing order to produce the intended graphics result.

CC>апдейтов к ним, так и примитивов отрисовки и прочей логической дельты + приличное и довольно умное кэширование всего на клиенте.
CC>Именно поэтому он такой эффективный.

Мде? ))
Откуда дровишки?
Тебе было с чем сравнить?
Наверно только с VNC, который по эффективности сливал первой нашей наколенной версии Application Sharing. ))
Там разработчики — линуховоды во всей красе.

А с Citrix хотя бы сравнивал?
А с расшаренным экраном в Скайпе?
Обычная там скорость, ничего выдающегося по сравнению с использованием обычного mirror driver и выбора способа кодирования перед передачей — всего изображения для области или разницы.

Причем, есть всякие трюки, которые позволяют заметно повысить отзывчивость. Например, мы ограничивали разрядность каждого цветового слоя для I-областей 4-мя разрядами (TrueColor — это 8 разрядов). А затем в последующем обновлении идут P-области (разница) с цветовым разрешением, скажем, 8 бит. Причем, эта разница, получается, придет только для слабоизменившейся или "застывшей" области. И вот такое огрубление даёт настолько дикий профит при сжатии по цветам, что всякие VNC нервно курят в сторонке. И уменьшение цветовой разрядности для динамических областей не особо заметно — глазу нужно время, чтобы сфокусироваться на неподвижном изображении. А кадры обновляются до 30 раз в сек (если были изменения), т.е. огрублённая по цвету движущаяся область изображения станет нормальной через 1/30 сек после своей остановки. А для совсем плохих соединений так и оставляли огрублённым до 4-х бит на слой — вполне себе неплохая для RDP картинка получалась, почти как 565 )).

Сравнивая с тем, что RDP тех времён:
— отключал обои стола;
— отключал сглаживание шрифтов;
— отключал темы;
— и т.д.
в итоге этот RDP смотрелся как кусок г-на и никто им всерьёз в те времена не пользовался.