#c# #image #google-maps #iis #opentk
#c# #изображение #google-карты #iis #opentk
Вопрос:
Я создаю пользовательское наложение пользовательских карт, используемое в частном порядке. Я не могу использовать сервер с открытым исходным кодом, такой как MapServer, из-за огромных объемов данных и формата, в котором они находятся.
Первоначально это было решение на стороне клиента, которое передавало клиенту ArrayBuffer и отображало данные на карте с помощью WebGL, однако позже мы узнали, что КОМПЬЮТЕРЫ наших пользователей будут без графического процессора, поэтому они не смогут плавно выполнять рендеринг WebGL.
Итак, я взял концепции и применил их к OpenTK — я создал обработчик сервера IIS, который создает экземпляр OpenTK и отображает запрошенный фрагмент.
Ради прототипа это работает, однако я чувствую, что это не лучшее решение.
Какой наиболее эффективный способ визуализации фрагментов?
Я бы хотел предварительно отобразить фрагменты, но слишком много наборов данных (добавляя еще 1000 в день!), Чтобы иметь возможность эффективно это делать.
Является ли OpenTK хорошим способом снижения (из-за аппаратного ускорения, которым он может воспользоваться?), Или слишком много накладных расходов при настройке экземпляра?
Или графические библиотеки C # — лучший способ изучения и использования?
Или даже — стоит ли отказываться от IIS и C # все вместе и использовать другой язык / фреймворк для обслуживания изображений?
Комментарии:
1. webgl или OpenTK без графического процессора окажут такое же влияние на производительность … если вы планируете веб-приложение, вам, безусловно, лучше использовать webgl…
2. В этом случае на сервере запускается OpenTK для предварительной обработки листов. Первоначальная идея заключалась в том, чтобы отображать на клиенте через WebGL, но отсутствие графического процессора делает это невозможным.
3. @Brad Zucher: сколько одновременных пользователей вы ожидаете? Будет ли каждый пользователь получать доступ к разным фрагментам? Сколько времени требуется для рендеринга одного фрагмента? Можете ли вы разработать эффективную схему кэширования? Здесь просто слишком много неизвестных, чтобы дать конкретный ответ.
4. @TheFiddler 100-1000 пользователей. В основном разные, да — много наборов данных. На данный момент для каждой плитки требуется ~ 0,4 секунды. Если бы я подумал об этом, я мог бы разработать достойную схему кэширования! Но наши прокси также выполняют много кэширования, когда я устанавливаю правильные заголовки! Я думаю, главный вопрос заключается в следующем: достаточно ли накладных расходов при запуске OpenTK, чтобы для каждой плитки было быстрее просто отображать. ЧИСТАЯ графика?
5. На вашем сервере установлен только один графический процессор, поэтому запуск нескольких экземпляров OpenTK будет значительно медленнее, чем запуск одного экземпляра и постановка в очередь листов для рендеринга. Переключение контекста внутри драйверов графического процессора причиняет боль. Последняя версия OpenTK запускается за миллисекунды, так что это не должно быть проблемой (но вам нужно будет измерить).
Ответ №1:
На вашем сервере установлен только один графический процессор, поэтому запуск нескольких экземпляров OpenTK будет значительно медленнее, чем запуск одного экземпляра и постановка в очередь листов для рендеринга. Переключение контекста внутри драйверов графического процессора причиняет боль. Последняя версия OpenTK запускается за миллисекунды, так что это не должно быть проблемой (но вам нужно будет измерить).
Комментарии:
1. Рисование одного фрагмента с помощью библиотеки рисования c # занимает столько же времени (~ 0,4 с), а рисование множества фрагментов намного стабильнее. Спасибо, что указали на переключение контекста.