LINUX.ORG.RU

Архитектура 'рисовальных' программ


0

1

Нужно написать програму с интерфейсом типа AutoCAD'a. Не такую навороченую, конечно.

Чтобы не изобретать велосипед задаю вопрос. Может есть какие-нибудь соображения о том как такое сделать? Или статьи какие на эту тему? То есть имеем рабочее поле, на котором расположено (в общем случае довольно много) примитивов (линий, окружностей и т.д.). С ними нужно взаимодействовать (перемещать). Все они на 1 экран не помещаются и нужно грамотно отображать части объектов, характерные точки которых не находся на экране (например концы отрезка вне экрана, а середина на).

Есть идеи?

★★★★

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

Заводишь список объектов, в котором имеется, как минимум, следущее: базовые координаты вершин объекта и "отображаемые" координаты. "Отображаемые" координаты, это базовые координаты перемноженные на матрицу смещения.

Есть виртуальное окно, в которое попадают объекты, которые необходимо отрисовывать. При изменении положения этого окна, пробегаем по списку, делая пересчёт "отображаемых" координат для всех объектов, далее, для каждого объекта делаем проверку попадает ли он в зону отрисовки и ставим соответствующий флаг. В цикле отрисовки, соответственно, отрисовываем только попавшиe в виртуальное окно объекты.

При выборе пользователем объекта, необходимо делать проверку, попала ли точка, куда он кликнул мышой, в полигон (елипс, e.t.c.) только для тех объектов, которые попали в зону отрисовки.

Узкое место в этой схеме, только сама отрисовка, но никак не пересчёт координат и проверка попадания объекта в виртуальное окно.

Есть два варианта, где, собственно, должен находится сам метод отрисовки: либо в обработчике OnPaint лепим switch, который в зависимости от типа объекта, дёргает нужную функцию оконной библиотеки, отвечающей за отрисовку, либо пользуемся виртуальными функциями и помещаем вызов фунции оконной библиотеки в подкласс объекта. Опытным путём, не смотря на то, что бытует мнение, что вызов вирт. фунций обходится дорого, разницы не установил. Всё время пожирают непосредственно функции рисования в оконной библиотеке.

Подобная методика позволила мне делать отрисовку сцены в 6000 _попадающих в виртуальное окно_ графических объекстов на 333 целероне за 8 милисекунд. 10-20 милисекунд при отрисовке сцены это вполне приемлимо, рывков при перемещении виртуального окна нет.

п.с. Всякие виджеты умеющие там что-то это слишком долго.

eRazor ★★★
()
Ответ на: комментарий от anonymous

;-) давно использую tkzinc - не сказал бы он обладает редкостной скоростью..Удобен - ДА, быстрый - пожалуй НЕТ..

anonymous
()
Ответ на: комментарий от vahvarh


>К сожалению, в QT-4 убрали canvas, точнее сказали что он >depricated.... Столкнулся с такой же проблемой (хочу щас написать >CASE средство и нужен аналог erwin в нём) - смотрел на diacanvas - >советую посмотреть, в нём даже perl-bindings есть, но мне не очень >пока понравилось... Возможно стоит самому написать... GTK вообще как >я понял не очень подходит для векторной графики... Потому что у него >есть только DrawingArea, а это pixmap и как говорится, "рисуйте сами >что хотите", вот QT3canvas был интересен (он как раз под векторы >хорошо заточен был) но как я уже писал выше - убрали.
>Так что я сам тоже в поиске - буду читать тред, смотреть что >предложили...


Не совсем достоверная информация. Просто портануть не успели:

http://doc.trolltech.com/4.0/porting4.html

Qt 4.1 is expected to provide a replacement module for these classes, based on Qt 4's powerful new 2D paint system.

Так что юзайте QCanvas на здоровье, такие вещи не выбрасываются.
Код там супер, лично изучал. Определяются участки, требующие обновления и обновляются лишь они.

Изобретателям велосипедов: просто посмотрите код сами. Даже переубеждать не придется.

Автору сабжа: есть пример на сотню(!) строк, делающий нечто похожее... Работа с объектами, перемещение, проверка попадания, масштабирование...

http://qt.osdn.org.ua/scale.tar.gz

ANDI ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.