САПР на Lazarus

[zub]

mtdu
Спасибо! а проц какой?
еще маленькое уточнение по ати - если выбрать мышью примитив он меняет цвет или становится пунктирным?

[mtdu]

Становится пунктирным.Проц. Intel Core 2 Duo 6300.
Пересобрал проект(в win пришлось закомментировать 522 строку, в Objinsp)

Код: Выделить всё

{$IFNDEF LINUX}self.VertScrollBar.Tracking:=true;{$ENDIF}

При включении сглаживания линий, время рендера увеличилось до 488.
Смена режимов восстановления изображения, ничего не дает,
только первые два плодят курсор(курсор не стирается).

[zub]

>>Пересобрал проект(в win пришлось закомментировать 522 строку, в Objinsp)
странно. {$IFNDEF LINUX} вроде не должен компилироваться под вин.

>>При включении сглаживания линий, время рендера увеличилось до 488.
у меня (на NV) оно никак не влияет на время. У вас стоят атишные дрова? похоже на microsoft generic драйвер

[mtdu]

Дрова последние атишные.
Catalyst™ Version 10.10, OpenGL Version 6.14.10.10237
Я так понимаю ATI, с некоторых пор вообще не поддерживает аппаратное ускорение OpenGL(или поддерживает не полностью) на обычных картах,(в линейке FirePro вроде поддержка полная) вот только это на уровне дров, или на уровне железа?
С другой стороны открыл тот же файл в акаде, конечно пошустрее но ненамного, а после выделения всех объектов, и вовсе разницы никакой.

[zub]

т.е. в инспекторе объектов на вкладке рендер\устройство АТИ упоминается?

>>С другой стороны открыл тот же файл в акаде, конечно пошустрее но ненамного, а после выделения всех объектов, и вовсе разницы никакой.
С автокадом сравнивать не стоит конечно)), но например qcad по производительности отображения гораздо медленней.

[mtdu]

скрин

[zub]

Аппаратное сглаживание линий видеопроизводители давно отдали на откуп FireGL\Quadro решениям, галочкой в риватюнере можно было отделаться только во времено RivaTNT насколько помню. ATI(AMD) видимо особенно нескромно об этом напоминает)).
488мс = 2fps без учета затрат кроме отображения. Собственно пока сшлаживанье линий у меня картинку больше портит чем красит, такчто фиг с ним))

[zub]

Таки всетаки хотелось бы услышать мнения по UNDO\REDO...
Вкраце: документ (чертеж) - список графических объектов (примитивов), примитивы могут содержать списки подпримитивов (вложенность не ограницена), всё это хозяйство может бруг на дружку ссылаться.
способы редактирования примитивов: командами, инспектором объектов, один примитив за раз или все выбранные.

Поштудировал интернеты - вроде самый подходящий способ разбивать все изменения чертежа на обратимые микрокоманды (классы с методами Do и UnDo в простейшем случае) и писать их в стек ундо, помечая начало и конец пользовательского изменения - вроде не очень сложно.
Как подобную архитектуру вписать паскальный синтаксис? Хотелось бы видеть примерно следующее:

Код: Выделить всё

Line:=ЛинияКоторуюПользовательТкнулМышкой;

UndoManager.StartUserCommand('Редактирование ткнутой линии'); //помещаем в стек маркер начала пользовательской команды с именем, чтоб пользователь потом видел что отменяет

Command:=UndoManager.CteateChangeCommand(Line.end); //тут ундоменеджер создает и помещает в стек микрокоманду изменения и запоминает начальное состояние изменяемого параметра, и адрес изменяемого параметра
Command.NewData.x:=новыйX;//
Command.NewData.y:=новыйY;//задаем новое положение, но не в линии а в команде, чтоб она его тоже запомнила
Command.NewData.z:=новыйZ;//
Command.Do;//или Comit, кароче применяем новое положение к линии

....
//аналогичным образом меняем начало линии или другие линии, короче "микрокоманд" между маркерами может быть много
....

UndoManager.EndUserCommand;//пихаем в стек маркер конца пользовательской команды

Насколько понял FPCшными генериками подобное не реализовать, т.к. их нужно руками специализировать для нужных типов и в UndoManager.CteateChangeCommand(Line.end) нужно передавать еще один параметр (для распознавания типа), чтоб там в большом CASE (тоже написаном рукаме) создать и вернуть нужную специализацию генерика команды.

[Odyssey]

Насколько понял FPCшными генериками подобное не реализовать, т.к. их нужно руками специализировать для нужных типов и в UndoManager.CteateChangeCommand(Line.end) нужно передавать еще один параметр (для распознавания типа).

Не вполне понятно, что представляет собой Line.end, и для каких типов нужно специализировать дженерики. Я почти совсем не в теме, но разве команды будут достаточно похожими, чтобы заюзать шаблоны?

[zub]

в данном примере

Код: Выделить всё

TLine=object start,end:tvertex; end;
tvertex=record x,y,z:double;end;

Подобных простейших типов в программе очень много, можно конечно просто выделять память и копировать, но придется постоянно приводить типы + внутри типа может оказаться string. Имхо было бы удобно иметь генерик с полями OldData и NewData специализированного типа и в них запоминать старые и новые значения.
Например захотим одну "микрокоманду" на изменение сразу всей линии - используем специализацию от TLine
Команды изменения объектов (которых будет 99%) будут похожи и отличаться только типом OldData, NewData. Сложные команды типа добавления\удаления примитивов в эти шаблоны входить небудут и писать их придется руками или шаблонизировать с похожими командами других типов.

Интересует мнение о пользе шаблонов в данном случае и варианты как красивее и короче сделать обертку над изменением параметров объектов для работы унды.

[Odyssey]

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

По поводу "передавать еще один параметр". Насколько я знаю, нормальными способами определить тип record'а и object'а нельзя, только через RTTI. Поэтому либо смотреть его, либо передавать информацию о типе. Либо, как бредовая идея в рамках мозгового штурма, изменить объекты/записи на классы, совместимые по API, т.к. классы будут хранить информацию о типе. Но это потребует значительных изменений в управлении памятью.

Код: Выделить всё

Command:=UndoManager.CteateChangeCommand(Line.end);
Command.NewData.x:=новыйX;

Command создаётся в рантайме, поэтому к NewData мы можем обращаться только как к одному типу -- тому, который указан в базовом типе команды (точнее тому, который возвращает UndoManager.CteateChangeCommand). Поэтому, имхо, вышеуказанный код заработает только если:
* мы его напишем на динамическом языке -- питоне, луа, и т.д.
* мы свалим в один тип(NewData) все возможные поля -- просто в кучу, или в variant record.
Одно страшней другого

Как вариант, можно написать кучу перегруженных для всех примитивов Command.SetData(XXX). Что-то типа:

Код: Выделить всё

var newline: tline;
...
Command:=UndoManager.CteateChangeCommand(Line.end);
newline.x = новыйX;
Command.SetData(newline);

[zub]

>>Имхо, лучше сначала сделать код для пары-тройки таких команд, а потом уже смотреть, можно ли убрать дублирование с помощью дженериков.
Я сделал с передачей адреса и sizeof, последующим выделением памяти и move, вроде работает (без стрингов внутри, но на этот случай на крайняк можно заюзать свой аналог RTTI реализованный в программе). Хочется посовременней, когдато ждал шаблонов наверно больше всех)), но так их и неиспользовал.

>>Command создаётся в рантайме, поэтому к NewData мы можем обращаться только как к одному типу
тут наверно можно выкрутится

Код: Выделить всё

with UndoManager.CteateChangeCommand(Line.end) do
NewData.x:=новыйX;


тип Line.end определен в компилтайм - должно работать, только вот какнибудь бы шаблонизировать CteateChangeCommand, чтобы получилась куча перегруженных функций создающих и возвращающих объекты разного типа.

[Odyssey]

только вот какнибудь бы шаблонизировать CteateChangeCommand, чтобы получилась куча перегруженных функций создающих и возвращающих объекты разного типа.

Насколько я знаю, шаблоны в FPC есть только для классов, для функций -- нет.

[zub]

>>Насколько я знаю, шаблоны в FPC есть только для классов, для функций -- нет.
блин. точно нет... чета какието недогенерики получаются((

Еще вопрс. при динамическом создании (используя getmem, не new) объекта (не class, именно object) инициализация compiler_magic полей компилятором не производится, остается на совести конструктора. При дальнейшем вызове деструктора для этого объекта в асме присутствует вызов fpc_finalize - как я понял финализация compiler_magic полей. Гарантировано ли финализируются все поля, независимо от вложенности и наследования? Спрашиваю потомучто в делфи с этим были проблемы - инициализировалсядеинициализировался только родитель, всё что к нему добавляли потомки оставалось нетронутым.

Добавлено спустя 4 часа 43 минуты 22 секунды:
Вообше тут получается какоето ООП противоречие - мы старательно прячем реализацию классов, выставляем наружу интерфейс, работаем с данными классов методами этих классов. И тут на тебе, какието "команды" должны иметь доступ к потрохам классов и копаться в них по своему усмотрению.

[zub]

Вроде чето получилось, команду изменения данных размножил генериком, процедуру создающую команду, размножил по старинке - макросом и инклудом. теперь достаточно вписать нужный тип в inc файл и можно применять консчтрукции вида:
изменение данных с последующим запоминанием в команде

Код: Выделить всё

with UndoStack.PushCreateTGChangeCommand(изменяемыйобъект)^ do //тут запоминается старое состояние
begin
        изменяемыйобъект:=чтотоновое;
        ComitFromObj; //тут запоминается новое состояние данных
end;

формирование изменений в команде с последующим присвоением данным

Код: Выделить всё

with UndoStack.PushCreateTGChangeCommand(изменяемыйобъект)^ do //тут запоминается старое состояние
begin
        NewData:=чтотоновое;
        Comit;//тут новое состояние из команды присваивается данным
end;

Вроде минимум изменений (только всё локализовать и обернуть) и никаких новых переменных, но небезопасно.Отсюда вопрос, можно ли внутри этих begin-end понять что PushCreateTGChangeCommand вернул nil, т.е. запихнуть в стек очередную команду неполучилось??

Как быть со сложными объектами, которые сами меняют свои данные своими методами? например пользователя приспичело промасштабировать или передвинуть полилинию. фактически это сводится к "домножению" примитива на посчитаную матрицу преобразования:

Код: Выделить всё

ВыбранаяПользователемПолилиния.TransformBy(matrix);

придумалось 3 варианта:
1)знакомить полилинию (все примитивы) с UndoStack чтоб она сама умела пихать в стек свои изменения внутри своих методов
2)полностью сериализовать полилинию до и после изменений и запоминать в команде
3)запоминать в команде matrix и инвертированную matrix
1 - много переделывать и неуниверсально, 2 - дорого по памяти, 3 - просто, но будет копить ошибку при undo\redo