на 10000 уже хорошенько подтормаживает в Linux

Ну под Linux (виртуальник) у меня примерное время отрисовки - ~170 ms, а под Windows ~120 ms (i5 2.8ггц).
Думаю это приемлемый результат, т.к. рисуются только те объекты, которые находятся в зоне видимости...
А разместить 10000+ элементов в одной зоне видимости будет нереально, да и незачем.
Под зоной видимости я подразумеваю видимый участок редактора схем, если что.
А так, в одном рабочем слое схемы, может находиться до 100000 элементов, но работать конечно будет уже не так комфортно, и лучше будет использовать контейнеры.
------------ Дoбавленo в 17.04:
Всё познаётся в сравнении, как говорится
На данный момент, по моим тестам, скорость расчётов и отрисовки всей рабочей области, выше чем у HiAsm 4 и намного выше чем у HiAsm 5.
У HiAsm 5 например, начинаются жуткие тормоза при нахождении в зоне видимости хотя бы 1000 элементов, что говорит об отсутствие оптимизации в этом плане.
Т.е. все объекты редактора схем, каждый раз при отрисовке скорее всего всегда рисуются с помощью базовых функций Rectangle, Ellipse и тд, что сильно замедляет весь процесс, т.к. каждый раз при отрисовке например, точки, функция заново вычисляет площадь закраски центральной части эллипса, потом границы и ещё нужно всё закрасить, и так каждый раз
Но всё можно ускорить, создав заранее канвасы с нужными состояниями точек, и потом просто вставлять их в нужное место, с учётом прозрачности, что в итоге даст прирост скорости в десятки или сотни раз.
------------ Дoбавленo в 17.47:
На днях кстати, начну пробовать портировать кодогенератор пакета Windows под lazarus, посмотрим что выйдет

Пару ошибок по находил.
Если взять элемент вытащить за границы экрана и отпустить то при возвращении элемент останется на мышке и будет за ней ползать. Один раз рабочая область ограничилась холстом который остался таким как форма до растягивания

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

elGetFlag:function (e:id_element):cardinal; stdcall;
//возвращает "хитрые" особенности элемента по его иденту

Это из CGTShare.pas.

Просто жуть
Что за "хитрые" особенности

CriDos, тема называется "HiAsm Open" и в маем понимании должны быть исходники. Или будешь все сам писать и потом кроме тебя никто не разберется

Редактировалось 2 раз(а), последний 2017-06-14 22:24:12

miver, это лишь наработки и проверка так сказать возможностей Lazarus'a и FPC в целом.
В дальнейшем придётся многое изменить под кодогенераторы, как только они будут хорошо изучены.

95.153.199.41, ну Linux таки за последние годы далеко успел шагнуть вперёд, и в этом ему помогают огромные сообщества со своими сборками.
А сейчас, когда на дворе 2014 год, кросс-платформа вообще должна быть обязательной и благо Lazarus отлично с этим справляется, так что затруднений в реализации независимого от ОС решения, не вижу.

А Виндус сделал пару шагов назад

Это очень гуд

Редактировалось 2 раз(а), последний 2017-06-14 22:24:13

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

Редактировалось 2 раз(а), последний 2017-06-14 22:24:13

Как только появится первая рабочая версия среды, нуждающимся можно будет приступать к портированию проекта на любую платформу.
Но базовой поддержки этой ОC не предвидится, т.к. архитектура сильно отличается от Linux и Windows систем, да и поддержки со стороны FPC/Lazarus нет...

Поддерживаемые для компиляции ОС: Linux, Microsoft Windows (Win32, Win64), Mac OS X, FreeBSD, WinCE, OS/2.

_Возможно_ в будущем появится проект HiAsm Next, цель которого станет поддержка как можно больше устройств и ОС, но это будет ещё очень не скоро.

Ошибаетесь, Linux сейчас хорош настолько насколько он раньше и мечтать не мог. Чего один btrfs стоит.
Пофиксят "детские болезни" и будет всё ок.

К слову HiAsm изначально нужно было развивать в направлении Linux+Windows(Linux первый в приоритете). Уже в то время на нём можно было бы нашлёпать пару десятков годных аудио- и видеоплееров, файловых менеджеров и прочего софта под Linux-ы. Это я ещё не говорю про софт для научной деятельности и для радиолюбителей.

А с текущим виндовым направлением получилось так, что linux-ам вообще ничего не перепало, абсолютно никакого вклада не было сделано.
Хотя по факту в мире Linux такая софтина как HiAsm была бы просто бомбой.

Повторю в 101-й раз.

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

DIXI, потому что устал
------------ Дoбавленo в 08.09:
Для обожателей Linux....

Встроенные приложения немыслимы без real-time требований. Вообще-то - любые приложения немыслимы, ну да ладно...
Я дико извиняюсь, но у меня есть серьезные сомнения насчет того, что эта "детская болезнь" будет преодолена.
Мне неизвестны RTOC вообще (а не только Linux), работающие с реактивностью хотя бы 20мксек на современных процах.
И уж тем более мне неизвестны RTOC вообще (а не только Linux), работающие в политике EDF (а не RMS)
------------ Дoбавленo в 08.10:
не сдержался, блин

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