Ну SVG, возможно, подошел бы как способ реализации отображения карты. Однако, ИМХО сабж весьма сложный и со сложностью нужно бороться. То есть, как минимум, разделять интерфейсы и реализацию. В качестве “виджета” я вижу связку типа Model – View – Controller, в которой главное - модель данных. И тут уже, по-моему, SVG совсем не подходит в качестве модели данных. Да и как способ отображения, по-моему, SVG - слишком уж медленно и не слишком элегантно (дополнительное преобразование данных из модели в XML, затем парсинг XML внутри QSvgWidget - получается ещё один лишний “тяжелый” интерфейс).
Давайте. Для начала хорошо бы более-менее окончательно определиться с целями и функциональными/нефункциональными требованиями.
А смысл?
Я немного (мне хватает) знаю шарп. Шарп меня всем устраивает. Для моей текущей цели он подходит.
Но вам желаю удачи - она вам очень сильно понадобится - за последнее время тут много проектов старотовало, но я ни одного не видел, который продвинулся дальше этого форумал.
Я когда-то тоже кодил на шарпе и считал его мега крутым языком и вообще платформой.
Помнится мне нравилось там быстро формы делать, всякие модные фитчи студии в этом очень помогали… кодить удобно)
Но политика майкрософта и запуск этого IL-кода на виртуальной машине мне очень не нравились. Скорость выполнения нативного кода + возможность контролировать все руками + столь же удобный кодинг при использовании сторонних либ типа буста и Qt + полная кроссплатформенность… ИМХО все это переплевывает все фишки связки шарпа+студия и оставляет её далеко позади)) ИМХО от архитектуры приложения многое зависит, можно и на шарпе написать нормально, и на можно С++ написать тормознутую хрень, но в целом нативный (не для .NET) С++ значительно быстрее.
На самом деле скорость выполнения такая же, как и у кода C++.
Другое дело скорость запуска, когда должен сначала загрузиться фреймворк. Это особенно важно для КПК. Хотя там и compact framework. :3
Нужно не путать назначение этого средства программирования… .NET это аналог-конкурент Java, а главная ниша продуктов написаных под виртуальные машины это монстроподобные энтерпрайз-приложения. … никогда бы раньше не подумал, пока не столкнулся с банковским софтом…раньше тоже казалось что весь серьёзный софт пишут на C и Cpp …ан нет…
И нет идеального языка, к которому надо придти “переболев” неправильными
Я например, волею судьбы, выучил язык 1С 7.7 … у меня после этого кардинально мнение поменялось в отношении его (а ведь очень многие его считают бейсиком на русском языке)
Для каждой задачи есть свой инструмент… и если C++ выбирать только потому что “он быстрее работает”…то это просто странно.
Что касается меня, С++ в решении данной задачи привлекает потому, что
Я с ним 10 лет маюсь
Пероносимость
Таки я полагаю, что на нем можно сделать не менее быстрый софт, чем на других языках, а в обратном - я не уверен.
А вот что плохо - опыта в написании для КПК тоже нет
Кстати, что думает общественность насчет рендеринга на OpenGL? в этом может быть какой-то смысл, или не стоит даже думать об этом?
Да, Garikk, С# как раз для “монстроподобных энтерпрайз-приложений” (с)
Несколько лет назад работал кодером, как раз подобные штуки писали… соединялки с базами данных, редактирование базы товаров, распечатка отчетов и т.д. Куча форм, талиц… и минимум нагрузки. Чтение/запись в базу данных, проверка вводимых значений и т.д. никаких сложных вычислений. Для 1С тоже скрипты простенькие писал… ввод/вывод, печать отчетов…
Для этого шарп подходит как никто другой, но вот рисовать на нем графу и писать приложения с шустрыми расчетами я бы не стал)
“Кстати, что думает общественность насчет рендеринга на OpenGL? в этом может быть какой-то смысл, или не стоит даже думать об этом?”
В случае с векторным отображением, для простой навигации в основном нужно только отображение статичной графики… это можно делать очень быстро используя VBO… практически без нагрузки на CPU. Главное что буфферы пересчитывать время от времени не нужно как в случае с редактором.
А что касательно растровых тайлов + векторный путь для маршрута, то тут все еще проще. Не знаю чем тайлы рисовать собираются, но вобще вывести текстуру из памяти видюшки намного быстрее чем тащить ее из оперативки. ИМХО в памяти видюшки держать небольшой кеш для тайлов довольно просто и очень полезно. Нарисовать маршрут оттуда-сюда можно одним VBO… пока считали граф, собрали все точки в кучу… запекли их в буффер, сгенерировали дополнительные точки и индексный буффер если хотим “дорожку”, а не линию. Дальше все в видюшке и она все делает сама… очень быстро.
А мне он запомнился своей неторопливостью. Впрочем, нужно посмотреть ещё… Судя по коду, если это то, что лежит в src/Render, то там есть простор для оптимизации. Кстати, кто тут говорил, что в коде меркартора разбирался?
Если не на КПК в традиционном понимании, то на всяких айпонтах, продвинутых ноклах и прочих модных гаджетах с функцией телефона встроенные видеоускорители весьма мощны. И что ещё немаловажно, они позволяют ускорять отрисовку 2D векторной графики (OpenVG). А Qt данную фичу с недавних пор уже использует.