САПР на Lazarus

[Sharfik]

а не проще один раз отрисовать в битмап (покрупнее шрифтом) а потом масштабировать уже битмап? бестрее будет.

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

картинка чтобы оценить размеры бедствия)) пунктиром видно треугольники из которых состоят глифы.

Я и так не нарисую)))

Вопрос, а можно предусмотреть в программе два режима окон - первый, это как сейчас в стиле панелек встраиваемых, и второй когда все в рознь, как сделано в Lazarus/GIMP?
Каждый раз мучался с панельками, когда пробовал попользоваться программой, и они либо становились столь большими что назад никак, либо куда то слетали.

[zub]

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

Прыгать небудут, но засчет масштабирования (gdi вообще умеет свободно масштабировать?) качество и скорость будут не на высоте. хотя я пока не проверял.

с памятью и сейчас невсе гладко:
Отчет о выделениях памяти довольно большой dxf файл, куча текстовых примитивов (отдельно тексты\мтексты не считал, т.к. многое спрятано внутри блоков, 4969 строк текста, 42329 символов, не считая пробелы и переводы строки) все рисуется ттф шрифтами

{EE569D51-8C1D-4AE3-A80F-BBBC565DA372}-Triangles TTF data 275359200
{93201215-874A-4FC5-8062-103AF05AD930}-Lines TTF\SHX data 172078208
{834B86B5-4581-4C93-8446-8CEE664A66A2} - содержимое переменных 11347168
Нужно для отладки 10485760
{AllocLine} 6112169
{5A1B005F-39F1-431B-B65E-0C532AEFA5D0}-GDBObjLine.Clone 3027608
{AllocText} 2359719
{AllocMText} 1957300

275359200 байт под треугольники, 172078208 байт под контуры букв. Эти цифры пока такие "гиганские", т.к. всё в двойной точности и всё отдельными треугольниками\линиями - пока не осилил STRIP\FAN режимы хранения геометрии, хотя триангулятор это позволяет. Современем думаю снизятся на порядок.

Тотже отчет для этогоже файла, но TTF шрифты заменены на romant.shx

{93201215-874A-4FC5-8062-103AF05AD930}-Lines TTF\SHX data 57607264
{834B86B5-4581-4C93-8446-8CEE664A66A2} - содержимое переменных 11347168
Нужно для отладки 10485760
{AllocLine} 6112169
{5A1B005F-39F1-431B-B65E-0C532AEFA5D0}-GDBObjLine.Clone 3027608
{AllocText} 2359719
{AllocMText} 1957300

Кэширование растрами\текстурами ситуацию с памятью несильно ухудшит))

Вопрос, а можно предусмотреть в программе два режима окон - первый, это как сейчас в стиле панелек встраиваемых, и второй когда все в рознь, как сделано в Lazarus/GIMP?Каждый раз мучался с панельками, когда пробовал попользоваться программой, и они либо становились столь большими что назад никак, либо куда то слетали.

Да, запустить с соответствующим ключем комстроки:
NLL - отключение загрузки файла докинга окон, окна открываются непристыкованными, но докинг работает
SI - полное отключение докинга, зкад работает в однооконном режиме (очень недоделанном)
UPDATEPO - отключение закрузки локализации, будет запущена английская версия. Также в этом режиме доступна команда обновления файлов локализации
NOSPLASH - отключение показа окна загрузки
путь/к/файлу.dxf - открыть указанный файл

Попробуй запустить:
zcad si
Докинга небудет, будет "жесткая" компоновка окон с инспектором слева. Пункты в меню вид отвечающие за показ окон\панелек будут глючить, т.к. не приспособлены к этому режиму, расчитаны на докинг. Не все команды будут присутствовать на тулбарах - надо подправить конфиг.

[скалогрыз]

Прыгать небудут, но засчет масштабирования (gdi вообще умеет свободно масштабировать?) качество и скорость будут не на высоте. хотя я пока не проверял.

gdi может масштабировать, но скажем ещё в winxp gdi умел делать только линейную интерполяцию с весьма поганым результатом.
Кажется в FPC/LCL уже есть функции для кубической интерполяции. Результат и скорость будут хорошими

Нужно заметить, что "кэширование текстурами в OpenGL", это тот же самый подход!

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

[zub]

>>Собственно кэшировать текст, который от кадра к кадру не меняется, это вполне естественный подход, вместо того, чтобы всегда отрисовывать сложную геометрию.
Не меняющееся изображение примитива это всетаки частный случай в ортогональной проекции, я не спорю, это тоже важно будет сделать, но после получения приемлимых результатов в чисто "геометрической" реализации с помощью треугольников. От геометрии всеравно никуда не денешся - например "выбор" текста мышкой растровыми средствами приемлимо точно не сделать.

>>Нужно заметить, что "кэширование текстурами в OpenGL", это тот же самый подход!
Тотже самый, но опенгл это точно сможет и выигрыш будет. как поведет себя gdi и его реализации под qt\gtk имея и рисуя с масштабом несколько тысяч битмапов нужно еще выяснить. Имхо разработать оптимальную систему лодов гораздо полезнее, а потом поверх нее возможно приладить растры

[zub]

Поэкспериментировал с StretchBlt, на увеличение "текстурок". Похоже этот способ неподойдет. отрисовка 1000 спрайтов ~70мсек, вентилятор проца воет заметно громче чем просто рисовать геометрию - т.е. аппараиного ускорения нету((. Никаких следов какойлибо фильтрации нет - картинка кшмар. Видимо тут нужен gdiplus, но он небудет кросплатформенным((

update:
Тут выше были жалобы про то что не режу отладочную инфу. В оправдание решил приделать генерацию крашрепортов - стек на момент краха и последние строки лога.
Получается очень странно - получить номера строк по стеку можно только один раз. Стандартный обработчик LCL выводит их в консоль и всё (насколько я понял это делает DumpExceptionBackTrace из LCLProc), в седующий раз по этим адресам никакой информации уже получить невыходит, даже повторный вызов DumpExceptionBackTrace пишет только адреса. Это фича такая или баг?
Получить информацию в своем обработчике можно только если подменить BackTraceStrFunc до краха (при старте программы)

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

StoreBackTraceStrFunc:=BackTraceStrFunc;
BackTraceStrFunc:=@SysBackTraceStr;

и восстановив ее обратно в своем обработчике.

[скалогрыз]

Поэкспериментировал с StretchBlt, на увеличение "текстурок". Похоже этот способ неподойдет. отрисовка 1000 спрайтов ~70мсек, вентилятор проца воет заметно громче чем просто рисовать геометрию - т.е. аппараиного ускорения нету((. Никаких следов какойлибо фильтрации нет - картинка кшмар.

а я же предупреждал! чтобы resizing был красивый нужно делать всё руками - надёжнее. На подлежащую систему лучше не надеятся.
Аппартного (графического) ускорения не будет, но скажем под конкретные модели процессора MMX, SSE и т.д. я уверен найти реализации возможно.

[zub]

В зкаде основная задача рисовать тоннами линии и треугольники, Софтовые растеризаторы тут на порядки отстают от аппаратных, даже от простого канваса - пробовал AGG:

http://sourceforge.net/projects/zcad/fi ... p/download

kubuntu 14.04 x64, kde 4.13.1:
qt:

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

OpenGL driver info: NVIDIA Corporation GeForce GTX 460/PCIe/SSE2 2.1.2 NVIDIA 337.25
Draw 100000 random lines
Canvas: 149msec
GDIPlus not avialible
AGG: 7411msec
OpenGL: 1msec

gtk2:

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

OpenGL driver info: NVIDIA Corporation GeForce GTX 460/PCIe/SSE2 4.4.0 NVIDIA 337.25
Draw 100000 random lines
Canvas: 348msec
GDIPlus not avialible
AGG: 7201msec
OpenGL: 2msec

windows7 x64:

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

OpenGL driver info: NVIDIA Corporation GeForce GTX 460/PCI/SSE2 4.1.0
Draw 100000 random lines
Canvas: 135msec
GDIPlus: 5297msec
AGG: 7885msec
OpenGL: 6msec

[zub]

Переделал лоды текста, сейчас гди рендерит сложные чертежи с ttf шрифтами с приемлимой скоростью. Раньше в сложных ситуациях время рендера одного кадра доходило до секунды, теперь максимум 100мс, типично 30..60мс. Лодятся теперь буквы, а не строки текста как раньше.
Паралельно наконецто вырисовался слой низкоуровневых графических примитивов, еще конечно пахать и пахать на этом поприще, но кад движек начал отделяться от графического.

[zub]

Поверх лодов букв вернул лоды строк текста, стало еще шустрее
Прилагаю анимированную гифку как оно теперь работает на гди:

Видно как сначала буквы "квадратятся", потом строчки заменяются линиями. В реальной работе масштаб меняется быстрее и эти процессы в глаза не бросаются. Но если критично - можно подрегулировать пороги и заменить линии на квады. оборвал запись при времени рендера 80, но это какойто нетипичный пик, типичное время для этого чертежа в большом масштабе - гди:45, огл:9
Теперь все примитивы в зкаде на низком уровне для отрисовки на экран представляются такой конструкцией:

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

ZGLVectorObject=object(GDBaseObject)
                                 LLprimitives:TLLPrimitivesArray;
                                 GeomData:ZGLGeomData;
                                 ......
                               end;

GeomData - просто массив вершин
LLprimitives - массив объектов "низкоуровневых" примитивов вида:

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

TLLLine=object(TLLPrimitive)
              P1Index:TLLVertexIndex; //индекс вершины начала линии в GeomData, P2Index=P1Index+1
              ....
        end;

Сейчас реализованы следущие "низкоуровневые" примитивы - линия, треугольник, точка, полилиния, символ, строка символов. Причем последние 2 это в больше "разметочные" примитивы, самми по себе ничего не рисуют, а помогают залодить.
В планах сделать "динамическую" регистрацию "низкоуровневых" примитивов и вместо простого массива LLprimitives сделать пространственное дерево чтоб с уровня DXF примитивов спустить выделение мышью на уровень "низкоуровневых" графических примитивов.

[zub]

Выложил версию с новым гди рендером http://sourceforge.net/projects/zcad/fi ... z/download если у кого есть под рукой слабенький комп - потестите пжста.
Запустить, в инспекторе на вкладке рендер переключить рендер бакенд с опенгл на гди, загрузить тестовый чертеж (меню отладка\sample files\ops.dxf), отписаться комфортности скролинга\зумирования

[Sharfik]

Выложил версию с новым гди рендером http://sourceforge.net/projects/zcad/fi ... z/download если у кого есть под рукой слабенький комп - потестите пжста.
Запустить, в инспекторе на вкладке рендер переключить рендер бакенд с опенгл на гди, загрузить тестовый чертеж (меню отладка\sample files\ops.dxf), отписаться комфортности скролинга\зумирования

Слабенький по видео или по всем параметрам? Напиши параметры своего, чтобы было понятно насколько ниже искать.

[zub]

Слабенький - больше по видео (встроенное или самая начальная дискретка), но и проц тоже желателательно ченить типа целерончика. Я имею возможность проверить только на i7+gf970 и i5+gf660

[kazalex]

отписаться комфортности скролинга\зумирования

Проверил на стареньком (10 лет) ноутбуке с Pentium M 1.7GHz, 512RAM, NVidia GF FX Go5200, Windows XP SP3. Рендер переключил, файл открыл, поскроллил, позумил. Вердикт - комфортно. Небольшие лаги есть только когда весь документ уменьшается до размеров окна просмотра, но это на юзабельность не влияет.

Обнаружил маленький косяк со скроллбарами (хотя, это, наверное, к LCL). Кликаем на бегунок скроллбара. Он, получив фокус, начинает мигать (тестировал на классической теме интерфейса винды). Зумим документ. В результате размер бегунка меняется, а мигающая область остается прежней.

[zub]

>>Pentium M 1.7GHz, 512RAM, NVidia GF FX Go5200
>>Вердикт - комфортно.
То что надо
По скроллбарам - да наверно к лцл - забывает изменить область пометки при изменении размера, но я на всякий случай починил съемом фокуса с них при надобности.
Спасибо!

[Sharfik]

Ничего не могу с собой поделать, люблю интерфейсы "украшать". Делал себе иконку для приложения и за одно на тему ZCAD пофантазировал. Файл ico содержит все иконки от 16 до 256 и с разной битностью.
https://yadi.sk/d/F7zL6KQQheykF