Разработка приложений, которые должны работать через RDP; какие-нибудь советы? - PullRequest
3 голосов
/ 10 июня 2009

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

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

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

Ответы [ 2 ]

3 голосов
/ 09 июля 2009

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

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

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

2 голосов
/ 10 июня 2009

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...