Библиотечная функция acedTextBox сильно тормозит программу.

[Baton]

Александр Ривилис,
При оптимизации программы по скорости ее выпонения вскрылась одна интересная подробность - библиотечная функция acedTextBox сильно тормозит программу. Функция эта мне нужна для получения размеров строки текста в Автокаде для впихивания строк в разные ячейки спецификаций и ведомостей. Без нее вроде никак. Ну вот такая печаль.

[Александр Ривилис]

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

Интересно шрифты TTF или SHX? Если TTF, то AutoCAD использует стандартные средства из Windows API.

[Baton]

Интересно шрифты TTF или SHX?

Для шрифтов TTF обработка строк функцией  acedTextBox примерно в 4 раза дольше, чем для шрифтов SHX.

[Александр Ривилис]

Интересно шрифты TTF или SHX?

Для шрифтов TTF обработка строк функцией  acedTextBox примерно в 4 раза дольше, чем для шрифтов SHX.

Вот это я и имел в виду. Если не нужна абсолютная точность, то можно пойти другим путём - получить габариты одного символа и размножить его по количеству символов. Есть еще метод AcGiTextStyle::extentsBox. Возможно он быстрее чем,  acedTextBox.
Пример его использования: https://adn-cis.org/forum/index.php?topic=7245.msg21588#msg21588

[Baton]

Есть еще метод AcGiTextStyle::extentsBox. Возможно он быстрее чем,  acedTextBox.

К сожалению, метод AcGiTextStyle::extentsBox не подойдет, так как строка может иметь индивидуальные настройки угла наклона, фактора ширины и т.п., а этот метод использует только  один параметр - стиль текста.

Если не нужна абсолютная точность, то можно пойти другим путём - получить габариты одного символа и размножить его по количеству символов.

К сожалению, ширина символа 1 и ширина символа 2 или Ш слишком сильно отличаются. Разница по размеру строки между 11111111 и 22222222 в итоге получается все-таки большой. Я поэкспериментирую, может пожертвую точностью. И сточки зрения времени интересно. 

[Debalance]

А разве AcDbEntity::getGeomExtents не решает этой проблемы?

[Baton]

А разве AcDbEntity::getGeomExtents не решает этой проблемы?

Из описания данного метода:
Derived classes should calculate and return the corner points (in WCS coordinates) of a box (with edges parallel to the WCS X, Y, and Z axes) that encloses the 3D extents of the entity, and return those points as an instance of class AcDbExtents in the "extents" parameter.

По переводу вроде все только параллельно главным осям? А текст может быть повернут относительно осей. Может я чего не так понял?

[Александр Ривилис]

А разве AcDbEntity::getGeomExtents не решает этой проблемы?

Нет. Даже если текст был бы не повернутый getGeomExtents не вычисляет достаточно точно габаритный контейнер для AcDbText/AcDbMText.

[Debalance]

По переводу вроде все только параллельно главным осям? А текст может быть повернут относительно осей. Может я чего не так понял?

Создать временный клон объекта с нулевым углом поворота - это микросекундная операция (если мы говорим об оптимизации).

... не вычисляет достаточно точно габаритный контейнер для AcDbText/AcDbMText.

Ну, во-первых, я так понимаю, acedTextBox вообще не работает с AcDbMText... правда? А во-вторых не совсем понятна формулировка "достаточно точно"... это как? Ваш вариант суммирования строки из отдельных символов тоже может быть "недостаточно точным" для определённых условий...

[Александр Ривилис]

... это как?

Просто неточный - для того чтобы ускорить операцию вычисления габаритного контейнера там всем пренебрегают. Впрочем, возможно и этой точности достаточно. Так как я не понимаю изначальную задачу, то не могу сказать достаточно ли этой точности или нет. Например, для определения того какой из ячеек таблицы должен принадлежать текст достаточно вычислить местоположение центра текста. Для этого достаточно и габаритного контейнера (даже поворачивать его не нужно). А если нужно нарисовать прямоугольник, в точности окаймляющий текст, то этой точности будет недостаточно.

[Debalance]

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

Судя по всему этого не требуется, ибо вот:

Функция эта мне нужна для получения размеров строки текста в Автокаде для впихивания строк в разные ячейки спецификаций и ведомостей.

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