fix(main_window): improve mouse scroll event handling for HiDPI support

[dengzhongyuan365-dev]

• Refactor mouse scroll point calculation to handle both raw and scaled coordinates, ensuring accurate detection within the recording area.
• Update logic to prioritize raw coordinates when both raw and scaled points are valid, enhancing usability in HiDPI scenarios.

This change addresses potential issues with mouse scroll detection in high-resolution displays, improving the overall user experience during screen recording.

bug: https://pms.uniontech.com/bug-view-360003.html https://pms.uniontech.com/bug-view-332693.html

[deepin-ci-robot]

deepin pr auto review

这份代码变更主要涉及两个方面的改进：HiDPI（高DPI）场景下的坐标处理优化，以及图像拼接时的边缘融合算法优化。以下是对这两处修改的详细审查意见：

1. src/main_window.cpp 修改审查

修改内容：
针对鼠标滚轮事件的坐标处理，增加了对 HiDPI 场景下"物理像素坐标"和"逻辑像素坐标"的判断逻辑，避免重复缩放导致坐标判断错误。

审查意见：

• 逻辑正确性：

  • 代码通过尝试 pRaw 和 pScaled 两种坐标来判断是否在录制区域内，这是一种有效的"试探性"修复方法，能够兼容底层回调可能传入不同坐标系的情况。
  • const QPoint mouseScrollPoint = (inRaw || !inScaled) ? pRaw : pScaled; 这行逻辑略显复杂。其含义是：如果原始坐标命中，或者缩放坐标未命中，则使用原始坐标；否则使用缩放坐标。这实际上倾向于优先使用 pRaw，除非 pRaw 明显不命中且 pScaled 命中。
  • 潜在风险：如果 recordRect 本身非常大（例如全屏），或者 x, y 坐标值非常小，可能导致 pRaw 和 pScaled 同时都在矩形内。此时根据逻辑会优先选择 pRaw。如果底层实际传入的是逻辑坐标（需要缩放），而这里误判为物理坐标，依然会导致计算错误。不过，注释中提到"底层回调...可能已经是'物理像素坐标'"，说明这是基于已知行为做的妥协。

• 代码质量与可读性：

  • 增加的注释非常清晰，解释了为什么需要这样做，这对后续维护很有帮助。
  • 变量命名 inRaw, inScaled 清晰明了。

• 改进建议：

  • 根本性解决：这种"试探性"逻辑虽然能解决问题，但不够健壮。最佳实践应当是在回调接口层面明确坐标系定义（例如统一规定为逻辑坐标），在接收数据的第一时间就完成转换，而不是在业务逻辑中进行猜测。
  • 逻辑简化：如果确认底层"常见情况"是物理坐标，可以直接判断 pRaw。只有在 pRaw 不命中时才尝试 pScaled。当前逻辑 (inRaw || !inScaled) ? pRaw : pScaled 中，!inScaled 这个条件可能比较宽泛。建议改为：

    // 优先尝试原始坐标（物理坐标），若不在区域内则尝试缩放后的坐标（逻辑坐标）
    const QPoint mouseScrollPoint = recordRect.contains(pRaw) ? pRaw : pScaled;

    这样逻辑更直观："如果是物理坐标就用它，否则当作逻辑坐标处理"。

2. src/utils/pixmergethread.cpp 修改审查

修改内容：
引入了 blendVerticalSeamBand 函数，在图像拼接时对重叠区域进行 Alpha 混合，以消除明显的拼接痕迹。

审查意见：

• 语法逻辑：

  • 函数参数校验非常充分，检查了空指针、图像类型、尺寸范围等，安全性较高。
  • OpenCV 的使用方式符合规范，利用了 convertTo 进行类型转换，利用 split 和 merge 处理通道，利用 repeat 生成渐变 Alpha 矩阵。

• 代码性能：

  • 优点：使用了 OpenCV 的矩阵运算（mul）代替了手写的双层 for 循环，利用了 SIMD 指令加速，性能较好。
  • 缺点/优化点：
    1. 内存分配：a.convertTo(a32, CV_32FC4) 和 b.convertTo(b32, CV_32FC4) 会触发内存分配。对于高频调用的拼接线程，频繁的内存分配/释放会增加开销。如果性能是瓶颈，可以考虑预分配缓冲区或使用 create 函数复用内存。
    2. Alpha 生成：alphaCol 的生成使用了一个 for 循环。虽然 bandH（模板高度）通常不大（代码中定义为 50），影响可以忽略，但也可以使用 OpenCV 的 range 或数学运算来生成，更符合向量化思维。例如：

       // 替代 for 循环生成 alphaCol
       cv::Mat range(bandH, 1, CV_32FC1);
       int indices[] = {0, 0}; // 沿着行方向
       cv::Mat indicesMat(bandH, 1, CV_32FC1);
       for(int i=0; i<bandH; ++i) indicesMat.at<float>(i) = i;
       // 或者更简单的线性生成逻辑，但 OpenCV 没有直接的 linspace，for 循环在这里也是可接受的。

       注：考虑到 bandH 很小，原代码的 for 循环完全可以接受，此处仅为探讨。

• 代码安全：

  • 类型安全：强制检查了 CV_8UC4 类型，防止类型不匹配导致的崩溃。
  • 边界检查：yDst + bandH > dst.rows 等检查防止了数组越界。
  • Alpha 通道处理：代码强制将 Alpha 通道设为 255。注释解释得很好：上游使用 ARGB32，保留源图像的 Alpha 可能导致拼接结果出现意外的透明斑块。这是一个正确的业务逻辑处理。

• 代码质量：

  • 函数封装：将融合逻辑封装为独立函数，提高了 splicePictureUp 和 splicePictureDown 的可读性。
  • 注释：注释详细解释了算法原理和业务背景（如 ARGB32），非常优秀。

总结与建议

1. main_window.cpp：

   • 修改解决了实际痛点，逻辑上可以接受。
   • 建议简化三元运算符的判断逻辑，使其更符合"优先尝试物理坐标"的直觉。
   • 长期建议：规范回调函数的坐标系定义。

2. pixmergethread.cpp：

   • 修改显著提升了图像拼接的视觉效果（消除接缝）。
   • 实现方式安全、规范，利用了 OpenCV 的优势。
   • 性能方面对于截图拼接场景（通常不是 60FPS 实时渲染）已经足够高效。如果未来需要处理极高帧率或极大分辨率，可考虑优化内存分配策略。

总体而言，这是一份质量较高的代码变更，解决了具体问题并保持了代码的健壮性。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dengzhongyuan365-dev, lzwind

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment