Разработка приложений, работающих по протоколу RDP; какие-нибудь советы?

Предположим, я разрабатываю приложение с достаточно интенсивной графикой (C ++ или C #, графический API не определен), для которого большая часть использования будет использоваться удаленными пользователями через RDP (либо сеансы терминального сервера, либо удаленный доступ к однопользовательской машине). Очевидно, что следует избегать второстепенных "леденцов" эффектов и анимации. Мои вопросы:

  • Что мне следует делать / чего не делать, чтобы максимально эффективно использовать протокол RDP? (например, у меня есть идея, что RDP может удалять некоторые примитивы графического рисования прямо клиенту ... но разве это только для GDI? Прерывает ли использование двойной буферизации такое удаленное взаимодействие и заставляет ли он работать в режиме растрового изображения? работают "или кэширует только определенные вещи, такие как шрифты и значки?)

  • Есть ли какой-либо анализатор протокола RDP, который даст некоторое представление о том, что на самом деле транспортирует поток RDP (в частности, растровые изображения и примитивы рисования)? (Я могу представить себе добавление некоторых инструментов в источник rdesktop для этого, но, возможно, что-то уже существует).


graphics rdp remote-desktop gdi terminal-services
person timday    schedule 09.06.2009    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

По сути, рекомендуется проверить код, работает ли он в удаленных сеансах (RDP, Citrix и т. Д.). Взгляните на: GetSystemMetrics( SM_REMOTESESSION ) - затем во время выполнения вы можете решить, включать или отключать определенные функции.

person Alan    schedule 09.07.2009

arrow_upward
2
arrow_downward

Я считаю, что работа по оптимизации, выполненная в RDP, уже покрывает 90% проблемы, которую вы описываете, поэтому я не буду беспокоиться об оптимизации для RDP, вы уже удалили приятные глазу вещи, вы знаете, что приложение будет используется через RDP, поэтому я полагаю, вы избежите операций, связанных с непрерывным перерисовкой формы, я считаю, что этого будет достаточно.

Наше приложение никогда не разрабатывалось с учетом RDP, у нас были те же опасения, что и у вас, когда клиент сказал нам, что весь его клиент будет использоваться через RDP (Citrix, в этом конкретном случае) из удаленных мест, но также и в том случае, если мы не изменим единственная строка кода, которую клиент никогда не вызывал из-за проблем с медленностью из-за RDP.

Помните ... Преждевременная оптимизация - зло.

person massimogentilini    schedule 10.06.2009