gjm/envi-code
1
0 Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
206 Commits 1 Branch 0 Tags
3c18a715a4122b52296341cfb9a6ba319b5ae8cb
Commit Graph
45 Commits
Author SHA1 Message Date
company-desktop b981fe930a perf: 护栏/爬梯等构件的管道副本改为"只存参数"，消除开图期 1140 次截面回写 
现象：开图期间 AecDbEwPipeBase::RegionAcisoutDwgOutFields 被调用 1140 次、耗时 2.38 s，
把截面写成临时 SAT 文件。用 AEC_WRITEBACK_TRACE 抓栈 + tools/resolve_rva.ps1 解符号，
定位到 AecDbZLineStair::DrawGuarBar3d 里的 pipe.clone()：
clone 走 AcDbObject → AecDbEwPipeBase::copyFrom → CopyObject（整实体 dwgOutFields/dwgInFields
往返），于是截面被写成临时文件再读回。

这些 clone 的唯一用途是存进 m_pipes，供 ToJson() 导出 __pipes__，而截面参数在
SetSection 时已经写进 spec XData（KEY_SECSHAPE / KEY_SIZE1 / KEY_SIZE2 / PIPE_THICK /
KEY_SECCEN），完全可以按参数重建。因此把"建几何"推迟到导出时：

- AecDbEwPipeBase::BuildSectionFromXData()：按 XData 参数重建截面（圆形/矩形；
  自定义截面返回 NULL，那种只能存在于 SAT 里）
- AecDbEwPipeBase::CloneParamsOnly()：生成只带参数（XData、放样线、实体属性、GUID、
  Breaks）、不含截面几何的副本，不触发任何序列化
- AecDbEwPipeBase::ToJson()：GetSection() 为空时回退到 BuildSectionFromXData()，
  保证 __section__ / __section2__ 仍然导出
- 30 处 m_pipes.push_back((AecDbEwPipe*)pipe.clone()) 改为 pipe.CloneParamsOnly()：
  ClimbStair(10)、ZLineStair(6)、BossHolder(4)、MRPLineStair(4)、Hanger(3)、Holder(3)

过程：先只改楼梯两个文件，回写从 1140 降到 960；再抓栈解析出剩余 960 全部来自
AecDbClimbStair::DrawLadderH3d，于是把其余 20 处一并改掉，最终归零。

实测（big1.dwg / AutoCAD 2020 / R230 Debug）：
  开图墙钟        初始 108~113 s  -> 缓存后 98 s  -> 本次 93 s
  开图期回写      1140 次/2.38 s  -> 1140 次       -> 0
  RegionAcisIn    3082 次         -> 3082 次       -> 1942 次
  临时文件        6773/9.34MB     -> 2694/3.34MB   -> 1733/2.34MB
  截面恢复总耗时  22.4 s          -> 9.87 s        -> 9.4 s

另外把 SectionPerf::TraceCallStack 的输出改写到独立的 aec_writeback_trace.txt，
不再写进 ENVIPERFDUMP 的报告文件（否则脚本会把"栈写出来了"误判成"开图完成"）。

验证：R230 Debug 编译通过并部署；用 tools/run_acad_perf.ps1 自动开图取数。
待验证：JSON 导出。m_pipes 里现在是不含几何的参数副本，ToJson 靠
BuildSectionFromXData() 重建，需要实际触发一次导出，确认 __pipes__ 里每条仍有
__section__ / __section2__ 且与改动前一致。
 2026-10-28 21:57:31 +08:00
company-desktop 7038a98441 diag: 用 PDB 解析栈帧，定位到 AecDbEwPipeBase::copyFrom 里的多余序列化 
上一版只给了"模块+RVA"的栈，我据此先后推断成
AecDbCurveBase::subGetTransformedCopy 和 AecDbEntityCommon::base_DeepClone，两者都是错的
（用户在那里下断点不命中；新加的 PerfTraceMark 打点也没有触发）。本次用符号解析定死。

本次改动：
- 新增 inc/PerfTraceMark.h：inline 的"某函数被调用过"打点，Debug 且 AEC_WRITEBACK_TRACE=1
  才生效。AecRxBase.arx 不链接 CoreLibrary（静态库只被 CoreCommand 链接），拿不到 SectionPerf，
  所以做成 header-only。
- 在 5 个候选入口打点：AecDbCurveBase::subGetTransformedCopy / subDeepClone、
  AecDbEntityBase::subDeepClone、AecDbEntityCommon::base_DeepClone、CKTCadUtility::CloneObject。
  跑一次开图，5 个都没触发 —— 这些候选被排除。
- 新增 tools/resolve_rva.ps1：用 dbghelp 的 SymLoadModuleEx / SymFromAddr 配本地 PDB，
  把"模块+RVA"解析成函数名。Windows 没有自带 symbolizer，这个脚本很轻，可反复用。

解析结果（CoreCommand.arx）：
  0x58f051  AecDbEwPipeBase::copyFrom+0x41
  0x7e1300  AecDbZLineStair::DrawGuarBar3d+0x2c0
  0x7e09d0  AecDbZLineStair::DrawSteep3d+0xbe0
  0x7ddcef  AecDbZLineStair::Draw3d+0x34f

真实成因：Z 型楼梯画护栏（DrawGuarBar3d）时 copyFrom 一份管道实体，
而 AecDbEwPipeBase::copyFrom 用通用的 CopyObject（inc/AecDbEntityCommon.h:331）
做"整实体 dwgOutFields/dwgInFields 往返"来拷字段，于是截面被写成临时 SAT 文件再读回来。

而且这次序列化是多余的：copyFrom 随后把所有字段又用内存级方式拷了一遍
（曲线 clone/copyFrom、截面 clone/copyFrom、XData CopyFrom、m_arUserInfs append、
标志位/图层/线型/Breaks 逐项赋值），WriteUserInterface 写的也只是 m_arUserInfs。
所以最小修改是把那句 CopyObject 去掉，并补上源为 NULL 时清空目标的分支
（目前这个"清空"是 CopyObject 顺带完成的）。

本次只做定位与记录（分析写进 pipe-section-region-performance-plan.md 并纠正了上一版的误判），
不改 copyFrom 的行为——它影响所有管系实体的复制粘贴/块内拷贝，需要单独验证。
 2026-10-28 21:28:00 +08:00
company-desktop 6d6f9ddaff diag: 统计回写的实体类，定位到 AecDbEwPipeBase 基类实例 
上一版只抓到"绘制期深拷贝"的调用栈，还没回答"是哪个类的实体在回写"。
现在 SectionPerf 增加按类统计的写回计数（NoteWriteBackClass），
在 RegionAcisoutDwgOutFields 里记一次 isA()->name()。

实测（big1.dwg，开图一次）：

  ---- write-backs by entity class ----
    1140     AecDbEwPipeBase

全部 1140 次都是 AecDbEwPipeBase 基类实例，不是 AecDbEwPipe 也不是具名子类，
与属性 key 统计里 AecDbEwPipeBase 的 1172 次几乎一一对应——
说明图纸里约有 1172 个基类实例（由 AecDbAssembleWell.cpp 的装配井代码创建，
多为矩形截面段），绘制期每个被深拷贝一次。

完整链路（已写入计划文档）：
  base_ViewportDraw -> AecDbCurveBase::subGetTransformedCopy
  （AecRxBase/AecDbCurveBase.cpp:307 里的 clone()）
  -> AecDbEntityCommon::base_DeepClone（AecDbEntityCommon.cpp:1232，dwgOut 在 1265）
  -> AecDbEwPipeBase::dwgOutFields（AecDbEwPipeBase.cpp:1440）
  -> AecDbEwPipeBase::RegionAcisoutDwgOutFields（AecDbEwPipeBase.cpp:1275）

顺带发现：AecDbEwPipeBase::copyFrom（:1605）复制截面用的是 m_pRegion->copyFrom()，
是内存级 ACIS 拷贝，比"写文件再读回"便宜得多。所以最局部的修法可能是给管系实体
加 subGetTransformedCopy 重载，用 isA()->create()+copyFrom() 代替 clone()，
绕开整条序列化链路；但 clone 与 copyFrom 语义不完全等价，需先核对。
本次只记录分析，不改行为。

验证：R230 Debug 编译通过并部署，脚本自动开图一次得到上述分类统计。
 2026-10-28 21:06:22 +08:00
company-desktop 67d6545e6c diag: 增加调用栈抓取，定位开图期 1140 次截面回写的成因 
现象：开图期间 EwPipe::RegionAcisout 被调用 1140 次、耗时 2.38 s，
把几何又序列化回 SAT。之前只知现象不知来源。

新增 SectionPerf::TraceCallStack()：用 RtlCaptureStackBackTrace + GetModuleHandleExW
把栈帧解析成 "模块名 + RVA" 并写进报告文件。正式代码里不开启，
只在 AEC_WRITEBACK_TRACE=1 时于 RegionAcisoutDwgOutFields 首次调用处抓一次。

结论（栈已定位）：
  subViewportDraw -> base_ViewportDraw -> ... -> base_DeepClone
  -> AcDbObject::dwgOut -> AecDbEwPipeBase::dwgOutFields -> RegionAcisout

即：不是保存，而是绘制期的深拷贝。AecDbEntityCommon::base_DeepClone
（AecRxBase/AecDbEntityCommon.cpp:1265）用
  AcDbDeepCloneFiler filer; GetMe()->dwgOut(&filer); pClone->dwgIn(&filer);
实现拷贝，于是每次克隆实体，截面都要写一个临时 SAT 文件再读回来。
读的那一半现在已被 kText 缓存吃掉，剩下 acisOut 写文件这半（2.38 s）。

顺带修正一个文档缺陷：inc/SectionPerfCounter.h 里 %TEMP%\aec_section_perf.txt
的注释之前被转义吃掉变成了 %TEMP%<BEL>ec_section_perf.txt。

修法（跳过深拷贝期的区域序列化 / 直接写缓存里的 SAT 原文）都需要动
AecDbEntityCommon 的拷贝契约或先审计 m_pRegion 的写操作，风险面不一致，
只把分析与三种方案写进 pipe-section-region-performance-plan.md，本次不改行为。

验证：R230 Debug 编译通过并部署；AEC_WRITEBACK_TRACE=1 跑图一次，栈如文档所示。
 2026-10-28 20:49:42 +08:00
company-desktop f8d10d5a3b perf: 增加截面 Region 缓存，开图恢复耗时降 56% 
一次开图要做 5641 次截面恢复（22.4 s），其中大量内容重复，
而每次恢复都是"写临时 SAT 文件 + 从盘 acisIn + 删文件"，单次 2.7~5.5 ms，
还要过一次杀软。本提交加一级母体缓存，命中直接 clone 返回。

新增 CoreLibrary/SectionRegionCache.{h,cpp}，三个通道按 key 的正确性强度分开：
- kParam：纯参数 hash，用于 AecDbEwFitting::GetSection 的两个重载
  （key = dD/dt/HLR 标志 或 W/H/dt/HLR 标志，同参数必同几何）
- kAttr：类名 + spec XData（排除编号，并跳过 Id/点/向量/矩阵/二进制类型），
  只给 AecDbEwPipe 用。AecDbEwPipeBase 是很多类的基类，其余派生类实例间的
  区别就是截面，不满足"同数据必同截面"，所以一律走内容 hash
- kText：SAT 文本内容 hash，用于 RegionAcisInDwgInFields 的其它类
  与 CoreTools::StringToRegion 的两个重载

约定：母体由缓存持有、永不外泄，Acquire/Put 都返回 clone，调用方拥有返回值；
母体不入库；每条通道 4096 条上限（AEC_SECTION_CACHE_MAX 可调），超出按 FIFO 淘汰；
AEC_SECTION_CACHE=0 可整体关闭做 A/B；卸载时 ClearAll() 释放，避免 DLL 析构顺序问题。

关键发现：SAT 文本第 2 行带存盘时间戳
  16 Autodesk AutoCAD 19 ASM 219.0.0.5600 NT 24 Thu Oct 22 10:19:20 2026
同一几何存盘时间不同，整份文本就不同（采样里两份 2596 字节的文本只差
10:19:20 与 10:19:16），这正是内容 hash 命中率只有 54% 的原因，与截面无关。
因此新增 HashSatText()：算 hash 时跳过第 2 行，仅当该行含 "Autodesk" 时才跳过。
计数器也改用同一口径，避免两套统计互相矛盾。

实测（big1.dwg / AutoCAD 2020 / R230 Debug，AEC_SECTION_CACHE 关 vs 开）：
  开图墙钟        108~113 s      -> 98 s
  截面恢复总耗时  22.4 s         -> 9.87 s（-56%）
    StringToRegion  14.05 s      -> 7.73 s
    RegionAcisIn     8.38 s      -> 2.14 s
  临时文件        6773 次/9.34MB -> 2875 次/3.61MB
  命中率          text 65.5% / attr 84.1% / param 88.8%
  clone 开销      命中 58us、未命中 73us（合计 0.37 s，可忽略）

顺带：
- tools/run_acad_perf.ps1 增加 -CacheOff 开关，用于同一构建上的 A/B 对比
- SectionPerfCounter 增加 AppendReport()，让缓存统计也写进同一份报告文件
- 诊断口子 AEC_SAT_SAMPLE=n 可导出未命中的 SAT 原文，用于定位这类差异

验证：R230 Debug 编译通过并部署；用脚本自动开图各跑一次（缓存关/开），
数据已写入 pipe-section-region-performance-plan.md。
尚未做：R190 编译（本机缺 v100 工具集）、Release 构建的收益复测、
开图期间 1140 次 RegionAcisout 回写（与本缓存无关，需单独立项）。
 2026-10-28 20:41:05 +08:00
company-desktop 764e544db4 perf: 增加属性 key 命中率统计（Phase 0 补充） 
意图：内容 hash 只看到 54% 命中率，但业务上"同数据的管子/管件截面必然相同"，
所以要用实体属性做 key 再量一次，决定 Phase 1 到底用哪种缓存键。

新增 SectionPerf::AttrKey（RAII）：
- 构造时按类名（isA()->name()）初始化 hash 与统计桶，析构时记一次
- Add() 增量喂字节，调用方决定哪些字段参与 key
- 统计按实体类分开（total / unique / hits / hit_rate）

接入 AecDbEwPipeBase::RegionAcisInDwgInFields：key = 类名 + 全部 spec XData，
但排除编号（"No."，每根管子唯一）并跳过 Id / 点 / 向量 / 矩阵 / 二进制类型
（与截面无关或随实体变化）。只在 AEC_PERF_COUNTER=1 时构建，Release 无开销。

实测（big1.dwg，AutoCAD 2020 / R230 Debug，113 s 开图）：

  属性 key 合计 3082 次 / 2672 命中 = 86.7%
    AecDbEwPipe       1088 次  173 唯一  84.1%
    AecDbEwPipeBase   1172 次    3 唯一  99.7%
       （其余类 43%~99%）
  内容 hash 54.0%

结论：属性 key 显著优于内容 hash，但只覆盖 3082/5641 次恢复
（另 2559 次走 CoreTools::StringToRegion，拿不到 spec 数据，只能用内容 hash）。
混合策略预计省 14.9 s / 22.6 s 恢复开销，约占 113 s 开图的 13%。

数据已写入 pipe-section-region-performance-plan.md，并标注一个未验证点：
属性 key 命中时两份 SAT 文本是否真的相同（决定 Phase 1 是否需要 textHash 兜底校验）。

验证：R230 Debug 编译通过并部署，用 tools/run_acad_perf.ps1 自动跑图取数。
 2026-10-28 20:06:06 +08:00
company-desktop 3f387485fd fix: 计数器改用 NDEBUG 判断构建类型（本仓库把 _DEBUG 剥掉了） 
现象：Debug 构建的 R230 里 ENVIPERFDUMP 报"未知命令"，计数器也永远不生效。

根因：cmakelists.txt 第 23~24 行会把 /D_DEBUG 从 CMAKE_CXX_FLAGS_DEBUG 里正则剥掉，
所以即使 --config Debug 编译，_DEBUG 也没有定义。于是 Phase 0 里用
`#if defined(_DEBUG)` 包住的命令注册和 Enabled() 判定整块被编掉——
已用二进制验证：修复前 arx 里查不到 ENVIPERFDUMP，修复后能查到（UTF-16 字符串）。

修复：改用 NDEBUG。cmakelists.txt 只对 Release 定义 NDEBUG
（`$<$<CONFIG:Release>:NDEBUG>`），所以 `#ifndef NDEBUG` 正好等价于"Debug 构建"。

- CoreLibrary/SectionPerfCounter.cpp：计数器启用条件
- CoreCommand/EarthWorm.cpp：ENVIPERFDUMP / ENVIPERFRESET 的函数定义与命令注册

验证：R230 Debug 两个 target 重新编译通过，产物已部署；
脚本自动开图后 ENVIPERFDUMP 正常输出（数据已记录到计划文档 Phase 0 实测结果）。
已知风险：`#ifdef _DEBUG` 在本仓库本来就不生效，rxdebug.cpp 等历史代码同样如此，
本次只修自己新增的两处，没有动别处。
 2026-10-28 19:52:18 +08:00
company-desktop 3afc2dd7c1 perf: 增加截面恢复路径的 Phase 0 计数器（Debug 探针） 
按 pipe-section-region-performance-plan.md 的 Phase 0 落地。目的不是提速，而是先拿到
三个决定性数字，再判断截面缓存（Phase 1）到底值不值得做：
1) 每次截面恢复多贵（µs），一次开图共多少次；
2) 同一份 SAT 文本被重复恢复多少次（唯一 hash 数 / 模拟命中率）——直接决定缓存收益上限；
3) 临时文件写入次数与字节数（杀软扫描影响面），以及打开图纸时的回写次数。

改动：
- 新增 inc/SectionPerfCounter.h + CoreLibrary/SectionPerfCounter.cpp
  - Scope（QPC 计时）+ NoteRegionText（FNV-1a 64 位 hash，统计唯一数与模拟命中）
    + NoteTempFile + NoteWriteBack + Dump/Reset
  - 计数器实例放在函数内 static：CoreLibrary 是静态库且只被 CoreCommand 链接，
    所以 CoreCommand.arx 里只有一份，两个入口共用
- AecDbEwPipeBase.cpp：RegionAcisInDwgInFields / RegionAcisoutDwgOutFields 接入
- CoreTools.cpp：StringToRegion 两个重载 / RegionToString 接入
- EarthWorm.cpp：注册 ENVIPERFDUMP / ENVIPERFRESET（仅 Debug）
- CoreLibrary/cmakelists.txt 加一个源文件
- 计划文档的 Phase 0 补上实际命令与采集项

开关：启动 CAD 前 set AEC_PERF_COUNTER=1；命令 ENVIPERFDUMP 打印并追加到
%TEMP%\aec_section_perf.txt，ENVIPERFRESET 清零。
Release 下 Enabled() 恒为 false，调用点只剩一次 bool 判断。

不改任何几何逻辑与存盘格式。

验证：R230 Debug 编译通过（CoreLibrary_BAL_REMOTE、CoreCommand_BAL_REMOTE，无新增 warning），
产物已自动部署到 c:\ShangHuaSoft\Envi3D-2026-M\R230\。
R190 未在本机编译（缺 v100 工具集）；代码刻意只用 C++98 特性，控制台输出改走 %hs，
避开了 &wstring[0] 这类老 STL 上的写法问题。
尚未做 CAD 实测：需要开图后跑 ENVIPERFDUMP 才看得到数据。
 2026-10-28 19:31:27 +08:00
gjm 9b80db3852 rafactor-pipe,fitting-speedup 
rafactor-pipe,fitting-speedup
 2026-10-27 22:29:12 +08:00
home-laptop 683863a5b1 修复 AecDbXSlab 的 L1-L9 内存泄漏 
- L1 GetOffsetCurve 失败分支补 FreeBuffer，不再整批泄漏 offset 曲线
- L2 CreatePipeRegion 的 booleanOper 操作数未释放，成功/失败路径均补齐
- L3 IsPointInSide 折线分支返回前未删 GetBasinShapeCurve 新建的曲线
- L4 Draw2d 圆板分支与无 KEY_ORGPT 分支中未进缓存的 pShape 泄漏
- L5 SetRegionSlab(LPCTSTR) 的 explode 碎片未释放
- L6 SetEllipseBasin 的 offset 曲线与多余截面 region 未释放
- L7 PeelBasinWall 的 explode 碎片未释放（SetBaseCurve 内部 clone）
- L8 SetProperties eXDB 分支的 pXYPoly 未释放
- L9 DrawHatch 未被 ConvertBoundCurve 接管的克隆、非 polyline 的 pCurve 泄漏
 2026-10-27 14:10:40 +08:00
gjm 2db02bbef5 Merge pull request 'refactor-i_aecdbxequipment-copyfrom' (#84) from refactor-i_aecdbxequipment-copyfrom into main 
Reviewed-on: https://git.ethereal-realm.top/gjm/envi-code/pulls/84
 2026-10-27 13:53:21 +08:00
company-desktop 8e071af21f refactor-i_aecdbxequipment-copyfrom 
refactor-i_aecdbxequipment-copyfrom
 2026-10-27 11:00:54 +08:00
home-laptop 39634dc86a 修复 XEquipment 参数 getter 的 M8-M10 缺陷 
- M8 DEF_KEY_FUNC 返回值改为值初始化，键缺失或类型不符时不再返回栈上垃圾值
- M9 getter 内对 m_pXDataMap 判空，避免空 map 构造的 impl 直接崩溃
- M10 GetType 读取 KEY_TYPE 失败时输出日志，不再静默返回 0
- 两份 DEF_KEY_FUNC 定义（XEquipmentImpl.h 与 ParamEquImpl.h）同步修改
 2026-10-27 10:57:20 +08:00
home-laptop 75819c0b72 修复 XEquipment 外壳/Impl 分离机制的 M1-M7 缺陷 
- M1 createParamEquImpl 成功替换前释放旧 impl，消除 inplace 编辑泄漏
- M2 copyFrom2 先克隆成功再替换，避免旧 impl 泄漏或被置空
- M3 copyFrom 补基类深拷贝并兜底重建 impl，修复 clone/复制得到空壳
- M4 在 XEquipmentImplBase 注明 impl 不拥有 xdata 的所有权契约
- M5 draw3dByImp 改用临时数组，绘制失败时保留旧 3D 缓存并提示
- M6 抽出 makeTempClone()，集中 ToJson 的克隆/补数据/拷 part 流程
- M7 getUniqueName 的 %s 统一传 LPCTSTR、修正 sizeof，XL 的 %d 改 %f
 2026-10-26 22:36:28 +08:00
gjm bc6996830f fix aecdbcamera.cpp 的链接错误 
fix aecdbcamera.cpp 的链接错误
 2026-10-26 21:26:40 +08:00
company-desktop 39dbab85bf 修复相机 HLR 结果处理中的三处正确性缺陷 
B1 mergeEnvelope：命中 isNull() 的 3DSOLID 时 pSolidAll 已赋值但未从 arptrs 摘除，
后续 deleteArrayVoidPtrs 会把它删掉，返回野指针。改为记下标、循环结束后统一 removeAt。

B2 process_result：outputWithoutID.append(entAr) 误写在 for 循环体内，每轮把累积数组
整体再追加一次，同一指针在 outputWithoutID 中出现多次，AddToModelSpace 第二次失败后
DELETE_PTR 会删掉已入库的实体。append 移到循环外，并先 entAr.removeAll()。

B3 process_result：erase 之后把 it 重置成 begin()，for 的 ++it 会跳过新的首元素，
多个构筑物时漏处理。改为 while + 先取 next 迭代器。

同时更新 HRL-MODEL-refactor.md：去掉未实施的内存账本方案，验证方法改为行为观察。
 2026-10-26 21:12:27 +08:00
company-desktop 14f7203f3b 修复相机 HLR 计算链路上的几处内存泄漏 
- hlrCalc 两处早退（HLR 结果为空、截面裁剪后为空）没有释放补充实体
  arAdditional_all，补上释放；第一处早退发生在轴网克隆插入 result1 之前，
  同时释放调用方移交所有权的 arAxisPtrs
- mergeEnvelope 找不到可用的 3DSOLID 时直接返回，漏掉 arptrs 里由
  GetDraw3dables 克隆出来的全部实体
- process_result 打成块失败时，subAr 里的实体没有被块表接管，需要自行释放
 2026-10-26 20:07:37 +08:00
company-desktop e555d29529 fix-aecdbcamera-崩溃导致双击无法退出 
fix-aecdbcamera-崩溃导致双击无法退出
 2026-10-26 14:04:38 +08:00
company-desktop e448dbacfd fix: GetInterface 数组版 bSizeUnLock 被 memset 清成 false 
inf.bSizeUnLock = true 原来写在循环外，循环内每次都 memset(&inf, 0, ...)，
赋值被清掉，数组版返回的接口实际一直是"锁定"状态。

把赋值挪到 memset 之后；循环外那两行初始化（bSizeUnLock / dGasket）删掉，
memset 之后本来就是 0。

bSizeUnLock 目前只在 i_AecDbXEquipment.cpp 里序列化，没有读取判断的地方，
所以此前没暴露成故障。
 2026-10-25 12:10:09 +08:00
company-desktop d1f4d0b50b fix: GetInterface 数组版补 dUnit，与下标版统一单位 
AecDbEwEquipment::GetInterface(AcArray<AecInterface>&) 里 ptPos 已经
transformBy(xform) 缩放过（米制 0.001），但 dSize1 / dSize2 直接取
pNoze->dVal1，没有乘 dUnit；下标版 GetInterface(int, ...) 是乘了的。
结果同一个接口经两个入口读出来尺寸差 1000 倍，出现"位置按米、尺寸按毫米"。

补 * dUnit。dV / dA 是电压电流（EarThwormDef.h:518），不是长度，不参与换算。

影响面：
- 数组版的 4 处内部调用（getOsnapPoints、subErase、DrawInfArrow、vtAdjust）
  只用 ptPos / vtDir，不受影响
- 外部消费 dSize1 的是 CoreCommand/pcf.cpp:1044 的 pcf_ewEquipment，
  米制图纸导出的 PCF 管径此前大了 1000 倍
- 毫米图纸 dUnit 为 1，行为不变

文档同步：3.7 补结论与影响面，3.12 标记确认不改，5.1 加第 16 项，
5.4 三项按结论更新。
 2026-10-25 11:58:00 +08:00
gjm a72b38c4e5 Merge pull request 'fix 修正自定义设备拖拽时的效率问题' (#53) from home-lenovo-legion-r9000/修正自定义设备拖拽效率 into main 
Reviewed-on: https://git.ethereal-realm.top/gjm/envi-code/pulls/53
Reviewed-by: gjm <littleoldpan@163.com>
 2026-10-25 11:43:22 +08:00
gjm 2931ab875c fix 修正自定义设备拖拽时的效率问题 
拖拽时一样走绘制缓存
 2026-10-25 11:29:19 +08:00
company-desktop f668e29b6c fix: 修复 AecDbEwEquipment 的 10 处逻辑缺陷 
3.2 subErase：sName.Find(_T("接头")) 当布尔用，找不到返回 -1 也为真，
    整个条件恒成立，删除任何设备都走阀门/接头的合并管线分支。补 != -1。

3.3 DrawHandFlg：else 分支写成 sFlag == _T("Y")，液动阀（3）符号文字一直是空串。

3.4 ProcessHlrResult：遍历 map 时 erase(it) 之后仍然 ++it。改成 while +
    erase(it++)，没有用 it = erase(it)，因为 R190 走 C++98 标准，
    C++03 的 map::erase(iterator) 返回 void。

3.5 GetSectionDraw：返回 nCount - nCoundPre（调用前减调用后），恒为 0 或负数。
    改为 nCoundPre - nCount。全库调用点都忽略返回值，此前无实际故障。

3.8 copyFrom：补拷 m_bVert / m_idDash / m_idCenter。原来复制粘贴竖放阀门
    会变横放，虚线与中心线的图层也丢失。

3.9 MakeBlockRefSet：判断的是累加器 ext 而不是本次的 extAdd，第一轮 ext 还是
    空状态，第一个实体的范围永远加不进去；块参照分支不 continue，extAdd 会
    沿用上一轮的值被重复累加。改为块参照跳过、extAdd 每轮新建并检查返回值。

3.10 byJson：br._len 是字节数，却按 new PVOID[br._len] 分配、按
     sizeof(PVOID)*br._len 拷贝，源缓冲区越界读 7 倍。改为按字节分配拷贝，
     并用 br._len 覆盖 m_nSize。

3.11 dwgInFieldsForXPrim：加 16MB 上限（kMaxXPrimDataSize），超限置
     eInvalidInput 让整个 dwgInFields 退出；readBytes 检查返回值，失败时释放。

3.13 GetBodyBox：恒返回 TRUE，调用方无法区分是否取到几何；_ext 在循环外定义，
     会把上一轮的累积结果重复并入。改为返回实际结果、每轮新建 _ext。

3.14 clearGeoBuffer：函数体只有 AssertWriteEnabled()，改完参数几何不刷新。
     改为 Clean2DBuffer() + Clean3DBuffer()。

未处理，见文档 5.4：3.6 HLR_CALC 序列化（要动 AecDbObjXDataMap 公共类）、
3.7 GetInterface 数组版单位（影响 67 处调用）、3.12 mat4 双次变换（需确认是否刻意）。
 2026-10-25 11:21:11 +08:00
company-desktop f6d701a661 fix: 存盘不再清空组合设备的子单元（m_Combins） 
dwgOutFieldsForXPrim 里的容错条件写成
  m_eType != kRevitCombination || m_eType != kRevitCombination
恒为真，任何单元存盘前都会执行 m_Combins.clear()：

- 组合设备（kCombination）写出去就是 0 个子单元，存盘一次几何永久丢失
- clear() 只清 vector 不释放指针，内存里的 XPrimData 全部泄漏
- 存盘是只读语义，原代码却在写盘路径里修改了对象状态

改为按实际有效数量写出，不修改对象状态；跳过 NULL 并单独计数，避免
"写了数量但循环少写一条"造成读写错位。同时删掉定义后未使用的 int num。

没有按原方案把条件改成 &&，也没有在读入端加过滤：m_Combins 只有组合
单元才会非空，写端正确后不存在"非组合类型带子单元"的数据，保留枚举
判断等于把正确性押在类型比较上，和原来的错误同源。

受影响的图纸里组合设备的子单元已经被写没了，无法从 dwg 恢复，不做数据
迁移。文档同步更新 3.1、5.2、5.4、6、8。
 2026-10-25 10:30:19 +08:00
company-desktop 41397130e2 refactor: 统一 XPrimData::m_pData 为字节数组，releaseData 只保留 delete[] 
releaseData() 原来按 m_eType 分两路（8 种 delete[]，其余 delete），但同一类型
在内存里可能是对象也可能是字节数组：开图、JSON 导入、深拷贝都分配 new byte[]，
而对话框里 setData<T> 的 default 分支和几处直接 new 分配的是对象。按类型判断
必然有一半场景不匹配。

- 13 处对象形式分配统一改成 new unsigned char[sizeof(T)]，后续 (T*)m_pData
  的用法不变
- releaseData() 去掉 switch，只保留 delete[]；~XPrimData() 改为先调 releaseData()，
  顺带修掉 m_Combins 子单元的 m_pData 泄漏
- AecDbEwEquipment::FreeSubPrimData() 取代 FreeBuffer(CPtrArray&)，改成成员函数，
  不再需要参数
- 另外三个文件作用域的 FreeBuffer/FreeBuffer2/FreeBuffer3 改名为 FreeEntityArray/
  FreeComplexCurveArray/FreeFaceplanArray，并加 static 收回内部链接
- 删除 ReleaseXPrimData，直接 releaseData() + DELETE_PTR
 2026-10-23 10:29:31 +08:00
company-desktop 03bbe08b76 fix: 修复 AecDbEwEquipment 的内存泄漏（夹点数组、几何单元、剖切与投影克隆） 2026-10-23 09:57:20 +08:00
company-desktop 8ca9519320 refactor: X3dPart 的懒加载标志改名 m_bNeedCreate 并加 mutable 
与 AcDbX3dSolid::m_bNeedCreate 对齐：同一个语义（派生几何缓存失效，
首次使用时再算），用同一个名字，避免 m_bDirty 被理解成"参数没写完"。
声明为 mutable，与 AcDbX3dSolid 一致；清标志仍在 Rebuild() 里做。
 2026-10-22 15:41:14 +08:00
company-desktop 5a5cd08721 perf: X3dPart 布尔结果改为按需重建，开图不再逐件建体 
方案 A（见 AcDbX3dSolid-refactor-plan.md 第 13 节）。开图慢的瓶颈是
AecDbX3dPartEntity::dwgInFields 无条件调 m_pPart->Create()，每个 part 都要
N 次建体 + N 次布尔。

A1：引入 m_bDirty
- AecDbX3dPart 增加 m_bDirty，构造/拷贝构造置 true
- 15 个改参数的接口置脏：AddX3dSolid、RemoveAt、RemoveAll3dSolidRec、
  SetOrgPoint、SetAxis、SetBoolOperFor、SetHide、SetActive、PeelOffTheSkin、
  AddMove×2、ResetMove、AddRotate、ResetRotate、CopyFrom
- 新增 Rebuild()（protected）：清标志后无条件重建，原 Create() 的函数体
- 新增 EnsureCreated()：m_bDirty 或 m_pSolid 为空时才 Rebuild

Create() 保持「显式调用一律重建」的语义，内部转调 Rebuild()。原因是外部
有 10 处先取 GetX3dSolid(0) 直接改（如 AecDbBDPipeBase:941 调 TransformBy）
再调 Create()，部件感知不到这类改动，做成幂等会漏掉重建。

A2：开图不建几何
- AecDbX3dPartEntity::dwgInFields 去掉 m_pPart->Create()，由
  AecDbX3dPart::dwgInFields 结尾置脏
- 读入口统一先 EnsureCreated：CreateDraw3dSolid、Draw3d、getOsnapPoints、
  GetForHouseSubtract

收益：关闭/冻结图层、视口外、XREF/审核/发布等不绘制的场景完全省掉建体与
布尔；全图可见时开图时间下降、首次 regen 补回。
 2026-10-22 15:07:18 +08:00
company-desktop 4fc910d6fd fix: 曲线通道重建截面时防崩溃 
RegionFromCurvesDwgInFields 里两处：

- isRegionNull(pRegion) && isRegionNull(pRegionBig) 改为 ||，原写法要求
  两个都无效才跳过，实际 pRegionBig 此时必非空，条件恒假，无效 region
  照样进布尔运算
- booleanOper 改走已有的 rawBooleanOperWrapper，ACIS 内部异常时由 SEH
  捕获，不再直接崩 CAD

顺带 delete pRegion：arRegPtrs 不拥有对象，原来 subtract 完没有释放。

曲线通道只读，spline 参数在写端从未落盘，几何缺失无法靠读端修复，
本次只处理崩溃路径，重建逻辑与启发式保持原样。
 2026-10-22 10:24:54 +08:00
company-desktop e3fff2ad66 fix: SAT 临时文件唯一化，修 DGJM.sat 读取越界 
1. AcDbX3dSolid::CreateFromSat 的 temp\temp.sat 改为
   temp_<pid>_<原子序号>.sat，用完 DeleteFile。原来固定名且从不删除，
   两个 CAD 实例同时从 SAT 重建时会互相覆盖。

2. DGJM.sat 的读取统一改成「分配时补终止符 + 按实际读到的长度赋值」：
   new char[n] 之后直接赋给 CString 会把未初始化内存当字符串读到终止符，
   现在 new char[n+1] + memset，再用 CString(pszTxt, nRead) 明确长度。
   涉及 AcDbX3dSolid、AecDbEarthWormFitting、DGJMDlg、GJYXJMDlg、
   JMDBDlg、JMSJDlg 共 6 处。

DGJM.sat 本身仍是固定文件名，写读双方靠它隐式传递，本次不改名。
 2026-10-21 23:39:47 +08:00
company-desktop 8630e2a499 fix: 未入库管道实体存截面时临时文件名不再撞车 
objectId() 为 kNull 时（剪贴板复制、临时序列化等），handle 取不到，
原来拼出来的文件名固定是 Region_<pid>_.dat，同一次存盘里所有截面共用
一个临时文件。

改为：句柄有效时仍用句柄，否则用进程内递增序号 N1/N2/... 作为后缀。
日志里的标识同步从 handle 改成 tag。
 2026-10-21 23:22:21 +08:00
company-desktop 8941246b16 refactor: 管道截面统一存 SAT，曲线写路径退役 
SectionRegionDwgOutFields 不再 explode 后按曲线写，改为固定写 nLen=0 +
RegionAcisoutDwgOutFields。读取端 nLen==0 本来就识别 SAT 通道，因此
kCurrentVersionNumber 保持 7，新图在老插件上仍可还原。

同时修 SAT 通道自身缺陷：
- RegionAcisoutDwgOutFields：临时文件名加进程号；new char[nLen] 补 +1 并
  清零；检查短读，短读或空文件退回原生写法，不再把未初始化内存写进 DWG；
  acisOut/Open 失败分支补 DeleteFile；两个重复的 errorfile 分支合并为
  WriteRegionNativeFallback，顺带修掉 7 字节泄漏
- RegionAcisInDwgInFields：临时文件名只取纯文件名，拒绝 DWG 里夹带的路径
  成分和盘符；errorfile 分支补 delete[]；create/dwgInFields/acisIn 失败
  分支加日志并正确释放；acisIn 返回的非 region 实体不再泄漏
- 删除 RegionExplodeDwgOutFields（写路径退役后无调用者）
 2026-10-21 22:15:49 +08:00
company-desktop f80ec56189 fix: AcDbX3dSolid 正确性小修（失败留痕/缓存失效/GSMarker/死代码） 
- StringToRegion 两个重载在 fixACISFormat 拒绝时打印长度与 SAT 首行，
  原来完全静默，现场只表现为构件消失，无法定位
- ReCreate 统一失效绘制缓存：清 m_pSolidDraw、m_arRegionFaces、
  m_pSubDMeshDraw。原来只有 AddMove/ResetMove/AddRotate/ResetRotate 清，
  TransformBy/SetSolidData/SetOrgPoint 调完 ReCreate 后 Draw3d 仍画旧几何
- GSMarker 改用独立成员 m_nGSMarker，不再借用 m_sszPoint2ds。
  后者在 kExtrude/kLoft/kSweep 里存断面/路径串，SetGSMarkerID 会覆盖成数字，
  导致 ReCreate 静默失败、几何丢失
- 删除 GetDrawSubDMesh 中 return 之后的 28 行不可达代码
- GetDraw2d / ByJson 补注释说明现状
 2026-10-21 15:31:27 +08:00
company-desktop 81215c8fe1 perf: AcDbX3dSolid 几何改为懒重建 
- 新增 m_bNeedCreate 标志与 EnsureCreated()：dwgInFields 与拷贝构造
  不再立即 ReCreate，延迟到首次访问几何时重建
- 开图时不再对每个单元逐个走 SAT 临时文件（acisOut/acisIn），
  显著降低开图耗时；Clone 也省掉一次重建
- 所有读取 m_pSolid/m_pSubDMesh 的入口统一走 EnsureCreated：
  GetNative3dSolid / GetDraw3dSolid / GetNativeSubDMesh /
  GetDrawSubDMesh / GetDrawSubDMesh2D / GetCentoridPoint
- GetDrawSubDMesh 补 m_pSubDMesh 空指针保护
- TransformBy 保持原有行为（参数变更后必须重建）
 2026-10-21 10:01:17 +08:00
company-desktop 581394622a fix #2 bug 
补充了对AecDbGuardBar,AecDbArcStair,AecDbLineStair 3种类型的判断.
 2026-10-20 10:06:34 +08:00
company-desktop 6b1add6c57 Update AecDbCamera.cpp 
删除AecDbCamera.cpp内的hlr相关的注释
 2026-10-20 09:29:26 +08:00
gjm 006b251370 Merge pull request '修复AecDbEwFitting剖切问题' (#17) from company-desktop-computer/feature/company-ai-dev into main 
Reviewed-on: https://git.ethereal-realm.top/gjm/envi-code/pulls/17
 2026-10-19 10:35:04 +08:00
company-desktop 2f8b639cea 修复AecDbEwFitting剖切问题 
修复AecDbEwFitting剖切后三维重绘不显示法兰问题
 2026-10-19 10:34:27 +08:00
gjm bbb899c0a0 fix: HLR 退化圆弧按来源实体直径判断，并支持爬梯 
在删除圆心角为 PI 的退化圆弧时，增加直径比较：
- 弯头(eElbow / eReduceElbow)：带法兰(连接类型 3/5)取法兰外径 m_dInterfaceD，
  否则取画法直径 m_dD；
- 爬梯(AecDbClimbStair)：取踏管直径 ClimbStair::dd。
仅当圆弧直径大于来源实体直径时才删除。

getElbowDiameter 改为 getSourceDiameter，removeFittingDegenerateArcs
改为 removeDegenerateArcs（已不止管件）。
 2026-10-16 23:20:57 +08:00
gjm c0c04952dc fix: HLR 结果中删除 AecDbEwFitting 产生的退化圆弧 
原 isDegenerateArc 以 弧长/半径 比值判断退化圆弧，且无法区分结果来源。
改为按来源实体类型判断：
- result1 的键是数据库实体 id，直接判断该 id 是否为 AecDbEwFitting；
- result2 的键是无 id 的补充实体指针，先经 mpAdditional
  (数据库实体id -> 其产生的补充实体) 反查归属的数据库实体 id，再判断。

删除规则：结果实体是 AcDbArc 且圆心角为 PI 时删除。
 2026-10-16 21:34:08 +08:00
company-desktop a1c7d39dc6 fix(HLR): 清理剖切结果中的退化圆弧，避免圆心角溢出生成反向大圆弧 
AecDbXCamera::hlrCalc 在 HLR 计算后新增 isDegenerateArc 判定：结果为 AcDbArc 且 弧长/半径 < 1e-6 时视为退化圆弧（圆心角极小），从 result1/result2 中删除，防止数值溢出把"很小一段"翻转成"反向的大圆弧"。
 2026-10-16 13:11:21 +08:00
company-desktop 0467086e65 重构: AecXData 类型标签改用枚举 AecXData::EType 
- 在 AecXData 内新增 enum EType，取值直接采用 wtypes.h 的 VARENUM(VT_*)，
  与原实现逐位一致（nVt 会序列化进 DWG/DXF/XData，数值必须保持不变）。
- 各模块共 303 处 nVt 判断由裸 VT_* 改为 AecXData::kTypeXxx，涉及 18 个文件；
  仅调试打印用的字符串字面量保持原样。
- AecDbObjXDataMap.h 增加 #include <wtypes.h>（EType 引用 VT_*）。
 2026-10-13 09:55:42 +08:00
gjm 164968b62e chore 
把非utf8-bom编码的cpp/h文件改为 utf8 bom 编码, msvc识别utf8编码时,如果不是bom格式的,会使用当前cp_oem来解码.
 2026-10-04 00:04:20 +08:00
gjm 8ac3fe9197 移除旧的 Visual Studio 工程文件，统一使用 CMake 构建 
删除 527 个 *.vcxproj、1 个 *.vcxproj.filters、2 个旧版 *.vcproj
以及 8 个 shs_image*.sln 解决方案文件（保留 StartApp C# 工程）。
 2026-09-28 15:53:36 +08:00
gjm 345044cb46 初始化提交 2026-09-28 15:28:50 +08:00