Управление вращающейся движущейся растровой картой

Question

Мое приложение представляет (растровую) движущуюся карту. Мне нужно уметь показывать поворотную базу карты под любым заданным углом. Программа в настоящее время на VC ++ / MFC, но проблема является общей. У меня есть исходное растровое изображение (CBitmap или HBITMAP) и я рисую его в контексте устройства (CDC), используя StretchBlt. Хотя это работает быстро и плавно для угла = 0 (и пользователь может плавно захватить карту с помощью мыши), это не тот случай, если я пытаюсь повернуть растровое изображение и затем представить его (вращение растрового изображения с помощью SetWorldTransform () или около того занимает сотни миллисекунд, и это слишком медленно).

Я думаю, что решение состоит в том, чтобы иметь возможность связывать только те пиксели, которые в данный момент находятся на экране, а не вращать исходное растровое изображение - и это ключ.

Если у кого-то есть опыт с подобной реализацией, это может сэкономить мне массу проб и ошибок. Спасибо! Avi.

Answer 1

Похоже, SetWorldTransform чрезвычайно медленный: http://www.codeguru.com/Cpp/G-M/bitmap/specialeffects/article.php/c1743

И хотя другие опции, представленные в этой статье, работают быстрее, есть, конечно, и другие лучшие решения, подобные этому: http://www.codeguru.com/cpp/g-m/gdi/article.php/c3693/ (также проверьте комментарии на предмет исправлений и улучшений)

Также вот некоторые не-Windows-ориентированные алгоритмы быстрого вращения: http://www.ddj.com/windows/184416337?pgno=11

Обратите внимание, что если вы гарантируете мощность в 2 измерениях, вы сможете значительно повысить скорость.

Answer 2

В ответ на мой вопрос и предоставленный ответ позвольте мне кратко изложить следующее:

1. Я использовал алгоритм, упомянутый в http://www.codeguru.com/cpp/g-m/gdi/article.php/c3693/.

2. Работает и обеспечивает довольно хорошую производительность и плавное отображение.

3. В нем были некоторые ошибки, которые мне нужно было исправить, а также упростить формулы и код в некоторых случаях.

4. Я рассмотрю алгоритм, упомянутый на http://www.ddj.com/windows/184416337?pgno=11, чтобы увидеть, обеспечивает ли он какой-то прорыв в производительности, который стоит адаптировать.

5. Моя реализация требовала использования большого исходного растрового изображения, поэтому мне нужно было изменить код, чтобы я не поворачивал все растровое изображение каждый раз, а только соответствующую часть, которая будет отображаться на экране (в противном случае производительность будет неприемлемой ).

Avi.