Если есть время, объясните пожалуйста, за счет каких механизмов "значительно быстрее, чем сырые файлы в ФС". Речь сейчас про передачу по сети или про выборку с диска вообще? Если про работу в целом, то что мне при работе с файлами, что СУБД приходится читать данные с диска и в этом отношении скорость постоянна. Если вы имеете в виду выигрыш в скорости за счет кэширования в объектной БД - то это не совсем верно, т.к. зная логику формирования растра из тайлов я реализовал эффективное кэширование с учетом пространственной близости соседних по географическим координатам тайлов.
Спасибо за совет (nginx). Пока надобности в нем нет (БД и единственный клиент в одной локальной сети). В дальнейшем, возможно, понадобится. На счет предварительной подгрузки максимально используемых тайлов - смысла нет, т.к. запрос любого фрагмента равновероятен (система используется для уточнении геопривязки поступающих снимков по текущему покрытию. Людей, которые рассматривают свои города, нет:) ). Упреждающее кэширование использую при просмотре карты.
Выравнивание известно, параметры компиляции моей библиотеки аналогичны параметрам компиляции ядра. Скорее всего остановлю текущую реализацию в виде структуры либо массив. Собственно вопрос был скорее про то, почему не компилируется вариант с частичной специализацией и нельзя ли это исправить (с шаблонами только-только познакомился). Чуть позже посмотрю указанную Вами тему
Армянское Радио: Спасибо за ответ. Ваш вариант не подходит по ряду "личных" причин. Одна из них - этот класс изображения - обертка над существующим мощным хранилищем растра с интеллектуальным тайлированием, свопированием, нативным отображением и проч. Это решение возвращает строку изображения в виде указателя на массив байт. В предложенном мною решению можно написать для каждой специализации вещи в духе
template
struct ImageType::PixelDefine {
typedef struct {
...
} Pixel;
};
...
Pixel* line = reinterpret_cast(scanLine(i));
и работать с потоком пикселей без лишних memcpy.