САПР на Lazarus

[zub]

А ниче поделывать и ненадо, я только за))
Сейчас зкад в нерабочем состоянии - перевожу поддержку shx\ttf на "новые" рельсы, уж больно она страшная после многих переделок - как допилю, закомитю.
Спасибо!

[Pavia]

По поводу скорости движков при рисовании 100 000 линий.
Вы видеокарту неправильно тестируете. 2 мс это время подготовки данных.
Из них 0.3-1 мс это for + random
Остальное это кэширование данных в драйвере без отрисовки.

У меня в драйвере есть настройка сколько кэшировать.
До 4 кадров. Драйвер ждет пока процессор сформирует до 4 кадра, и только потом рисует.

Надо брать более 10 кадров и усреднять результат. Я для чистоты эксперемента взял 1 000 кадров и усреднил результат.
Получил такие цифры от 10 до 36 мс .

OpenGL driver info: Intel Intel(R) HD Graphics 4600 4.2.0 - Build 10.18.10.3355
OpenGL driver info: NVIDIA Corporation GeForce GT 750M/PCIe/SSE2 4.5.0 NVIDIA 353.30

10 мс максимум производительности NVidia
26 мс минимум производительности NVidia
21 мс максимум производительности Intel
36 мс минимум производительности Intel



Рисование линий это процессорная обработка. Т.е она в видео карте в принципе не отличается от CPU
там и там это софтварный движок. Технически по другому не сделать.
Просто на GPU он лучше оптимизирован плюс железные плюшки. За счёт этого и работает быстрее, но не моментально.
А так под CPU тоже можно увеличить скорость только возиться много надо.

[zub]

Я не специалист по графике и не претендую на стопроцентную достоверность тестов. Но позвольте не согласиться))
Наверно можно добиться полной асинхронности видеокарты и цпу с убеганием цпу на n кадров вперед, но у меня этой цели нет и асинхронности соответсттвенно тоже нет.
Я использую двойную буферизацию и условно отрисовка устроена так:
1-начало замера времени
2-отправка данных для отрисовки на заднем буфере
3-запоминание содержимого заднего буфера, для последующего быстрого восстановления при необходимости без перерисовки
4-переключение буферов
5-конец замера времени

>>У меня в драйвере есть настройка сколько кэшировать.
Я использую glFlush (или как ее там) - эта настройка не работает. У меня кстати там стоит 1

то что на шаге 3 запоминается нормальная дорисованная картинка говорит о том что отрисовка идет паралельно с отправкой данных и картинка готова еще до переключения буферов. Так что замер времени более-менее верный и имхо нижние и верхние "пики" циферек видеть гораздо полезнее чем усредненный результат.

Отрисовка линий видеокартами хардварно ускоряется - стопроцентный факт - можно убедиться отключив аппаратное ускорение и глянуть разницу показателей. ЕМНИП на игровых видеокартах не ускоряются только линии с антиалиасингом

>>А так под CPU тоже можно увеличить скорость только возиться много надо.
Писать софтварный рендер у меня цели нет, да и наврятли получится лучше чем agg, а его результаты совсем не впечатляют... (подозреваю что дело там не в рисовании линий а в затратах на пересылку растра в гпу).
В случае гди\гди+ скорость упирается именно в сами гдишные функции рисования, остаются только всякие оптимизации типа отсечения невидимого и лодов - они у меня одинаковы как для опенгл, так и для гди.

зы. Возможно в gditest который был тут несколько страниц назад я ченить и накосячил с асинхронностью, но в зкаде точно нет
зыы. Поглядел gditest, да glFlush там нет, но его добавление на результат не влияет - теже минимальные результаты, на грани погрехности замера времени

[zub]

Ну, вот так работает из OnCreate формы:

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

With TComboBox.CreateParented(Handle) Do
  Try

   Self.Caption := Format('ComboBox.Height = %d', [Height]);

  Finally

   Free;

  End;


Проверил на XP и Ubuntu (GTK2) - везде актуальные значения.

В последних ревизиях Lazarus этот способ отвалился, что собственно и стоило ожидать от подобного хака((

[kazalex]

В последних ревизиях Lazarus этот способ отвалился, что собственно и стоило ожидать от подобного хака((

Не факт, что это не баг LCL. У меня вчера на одной форме якорная привязка к TEdit поехала на на виндах младше семерки.

[zub]

>>Не факт, что это не баг LCL. У меня вчера на одной форме якорная привязка к TEdit поехала на на виндах младше семерки.
Не факт. Но не факт и то что фича из делфи для размещения своих контролов на чужих формах вообще должна работать в лазаре (на невиндовых виджесетах), пока убрал это дело до лучших времен

[kazalex]

Но не факт и то что фича из делфи для размещения своих контролов на чужих формах вообще должна работать в лазаре (на невиндовых виджесетах)

В LCL каждый виджетсет должен реализовать метод SetParent(), к вызову которого, в конечном итоге, сводится назначение родительского окна. CreateParented был использован для краткости, но можно заменить на прямое назначение:

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

With TComboBox.Create(NIL) Do
  Try

   ParentWindow := Self.Handle;
   Self.Caption := Format('ComboBox.Height = %d', [Height]);

  Finally

   Free;

  End;

[zub]

>>CreateParented был использован для краткости, но можно заменить на прямое назначение:
Сути это не меняет - создание контролов в винде (в других виджесетах хз) событийно ориентированное и имхо то что CreateParented работает (он вроде снова заработал) чудо какоето. Буду юзать пока снова не отвалится или не допилят соответствующий функционал в themes.

Тем временем переделал shx\ttf на описаные выше "низкоуровневые" примитивы, паралельно пофиксив чудовищьную жрачку памяти для ttf.

[kazalex]

создание контролов в винде (в других виджесетах хз) событийно ориентированное

Переведи: "событийно-ориентированное создание контролов".

[zub]

Да криво сказал)) имелл ввиду что сам по себе вызов create ничего не значит, действия происходят потом, в оконной процедуре куда приходят всякие wm_create, wm_size, отсюда и изначальные проблемы - сразу после создания возвращаются неверные значения.

Кстати, причесывал утечки памяти - CreateParented(Handle) подтекает - несколько раз созается FItems, предидущие значения утекают; c ParentWindow := Handle такой проблемы нет.

[kazalex]

CreateParented(Handle) подтекает - несколько раз созается FItems, предидущие значения утекают; c ParentWindow := Handle такой проблемы нет.

Пардон муа, какие ещё предыдущие значения при вызове контруктора от имени класса??? Паскаль, конечно, позволяет вызвать конструктор от имени объекта, но такие тонкие моменты вообще мало кто учитывает, и LCL уж точно этим не парится.

[zub]

Скомпильте свой пример с heaptrace, получится както так:

E:\zcad\cad\zcad.exe nosplash updatepo qnll qsi
Heap dump by heaptrc unit
2376760 memory blocks allocated : 142560943/150483368
2376758 memory blocks freed : 142560695/150483112
2 unfreed memory blocks : 248
True heap size : 101253120
True free heap : 3796160
Should be : 101252736
Call trace for block $15B49510 size 124
Block content: 34AA78000000000008BF7500000000000000000000000000000000000000000000000000B404190000000000A895AB1700000000000100004801000049010000460100004B010000440100004A010000430100005001000051010000470100004E010000000000000000000000000000000000006101000008000000 -
4
$005B57BD TWIN32WSCUSTOMCOMBOBOX__GETITEMS, line 1069 of ./win32/win32wsstdctrls.pp
$00582CA5 TCUSTOMCOMBOBOX__INITIALIZEWND, line 31 of ./include/customcombobox.inc
$0056AA19 TWINCONTROL__CREATEWND, line 7456 of ./include/wincontrol.inc
$0056A2D1 TWINCONTROL__CREATEHANDLE, line 7340 of ./include/wincontrol.inc
$0056B431 TWINCONTROL__HANDLENEEDED, line 7786 of ./include/wincontrol.inc
$005642C4 CHECKHANDLEALLOCATED, line 3446 of ./include/wincontrol.inc
$00563F94 TWINCONTROL__DOALLAUTOSIZE, line 3497 of ./include/wincontrol.inc
$BAADF00D
Call trace for block $002AC678 size 124
Block content: 34AA78000000000008BF7500000000000000000000000000000000000000000000000000B404180000000000B059DF0E00000000000100004801000049010000460100004B010000440100004A010000430100005001000051010000470100004E010000000000000000000000000000000000006101000008000000 -
4
$005B57BD TWIN32WSCUSTOMCOMBOBOX__GETITEMS, line 1069 of ./win32/win32wsstdctrls.pp
$00582CA5 TCUSTOMCOMBOBOX__INITIALIZEWND, line 31 of ./include/customcombobox.inc
$0056AA19 TWINCONTROL__CREATEWND, line 7456 of ./include/wincontrol.inc
$0056A2D1 TWINCONTROL__CREATEHANDLE, line 7340 of ./include/wincontrol.inc
$0056B431 TWINCONTROL__HANDLENEEDED, line 7786 of ./include/wincontrol.inc
$005642C4 CHECKHANDLEALLOCATED, line 3446 of ./include/wincontrol.inc
$00563F94 TWINCONTROL__DOALLAUTOSIZE, line 3497 of ./include/wincontrol.inc
$BAADF00D

По ходу выполнения CreateParented 3 раза вызывается TWIN32WSCUSTOMCOMBOBOX__GETITEMS, результат запоминается в FItems каждый раз переписывая и не уничтожая предидущие значения. Соответственно результат последнего вызова в дальнейшем подчищается в деструкторе, а первый и второй (2 пустых стринглиста) благополучно утекают.
Париться или не париться по этому поводу - личное дело каждого - страшного ничего в этом нет, если не создавать постоянно тонны контролов с помощью CreateParented. Я предпочитаю чтоб утечек небыло, хотябы раз в год, когда до них доходят руки))

[kazalex]

Дело не в CreateParented, а в конструкторе Create, который не учитывает, что FItems могут быть уже проинициализированы на момент его работы. По хорошему-то это в трекер нужно.

[zub]

Про CreateParented можно многое на багтрекер написать)) - в Qt например созданый ей контрол после деструктора иногда оставался "фантомно" болтаться на форме, приходится перед уничтожением ему делать hide на всякий пожарный, в винде ловил случайные вылеты при закрытии программы (не факт что это не мой косяк - детально не разбирался, но поверхностные разборки указывают на CreateParented). Конечно можно списать на транковый лазарь, но доверия к CreateParented не добавляет - убрал ее, и всё работает((

[zub]

Приделал к ттф нормальный лод - при маленьком размере в контурах глифов отрисовываются только вершины помеченые on_curve, вершины сгенерированные безье решалкой отбрасываются