first decomp and analysis

docs/surveillance-client-dpi-next-steps.md

@@ -0,0 +1,152 @@
+# Surveillance Client DPI Next Steps
+
+Date: 2026-03-25
+
+## Goal
+
+Find the lowest-risk path to make the legacy client usable on high-resolution monitors without breaking multi-window video layout behavior.
+
+## Recommended Work Plan
+
+### Phase 1: Establish Runtime Baseline
+
+1. Test the current executable under Windows with no compatibility overrides.
+2. Test with external manifest variants or compatibility settings that force:
+   - DPI unaware
+   - System DPI aware
+   - Per-monitor aware
+3. Capture screenshots and note:
+   - overall UI size
+   - text crispness
+   - icon scaling
+   - video view scaling
+   - behavior when moving between monitors with different DPI
+
+Reason:
+
+- This determines whether the practical answer is an OS-scaling solution or a true binary patch.
+- For a Qt 4-era application, this experiment can save a lot of unnecessary reverse engineering.
+
+### Phase 2: Finish Startup Mapping In Ghidra
+
+1. Trace `0x004c7260` in more detail until the `QApplication` constructor call is isolated.
+2. Identify the first top-level widget or main window constructor.
+3. Identify where `show`, `showNormal`, or `showFullScreen` is first invoked for the main UI.
+4. Identify where `window_status` data is applied back onto live windows after `load_window_status_from_settings`.
+
+Reason:
+
+- If a binary patch is needed, the ideal injection point is after `QApplication` exists but before the first user-visible window is shown.
+
+### Phase 3: Decide On Patch Strategy
+
+#### Option A: Keep The App DPI-Unaware And Let Windows Scale It
+
+Use this if:
+
+- the UI becomes acceptably sized
+- video rendering remains correct
+- visual blur is acceptable
+
+Advantages:
+
+- lowest engineering risk
+- no need to understand all custom Qt painting and layout code
+- least likely to break camera preview surfaces
+
+Risks:
+
+- text and controls may remain blurry
+- behavior may vary by Windows version
+
+#### Option B: System-DPI-Aware Patch Plus Geometry Reset/Migration
+
+Use this if:
+
+- the app looks tiny now because it is already treated as DPI aware in some configuration
+- Qt scales fonts and base metrics acceptably at startup when system DPI is exposed
+
+Required work:
+
+1. Add or patch early DPI-awareness setup before UI creation.
+2. Clear or rescale persisted `windowGeometry` and related layout state.
+3. Verify icons, toolbars, tab metrics, and preview panes at 125%, 150%, and 200%.
+
+Risks:
+
+- still no clean per-monitor behavior
+- custom pixel-sized controls may remain too small
+
+#### Option C: Application-Side Qt Scaling Retrofit
+
+Use this if:
+
+- Windows scaling is visually unacceptable
+- a crisp interface is required
+
+Required work:
+
+1. Patch after `QApplication` creation.
+2. Scale fonts globally.
+3. Scale icon sizes and style metrics.
+4. Scale or invalidate stored `QRect` window geometry.
+5. Verify custom widgets and video panes.
+
+Likely implementation ideas:
+
+- patching application font defaults
+- patching style pixel metrics through an existing proxy style path
+- scaling saved geometry before it is applied
+- forcing a first-run reset of `window_status`
+
+Risks:
+
+- highest reverse-engineering effort
+- most likely to require multiple iteration cycles
+
+## Specific Reverse-Engineering Targets
+
+The next Ghidra pass should answer these exact questions:
+
+1. Where is `QApplication` constructed?
+2. What function creates the main window?
+3. Where does the program apply `windowGeometry` from `QSettings`?
+4. Are there custom widgets using hardcoded pixel sizes?
+5. Are video preview surfaces tied to raw pixel assumptions that could regress under scaling?
+
+## Settings To Watch Closely
+
+These keys are likely to interfere with a DPI patch and should be considered for migration or reset:
+
+- `mainwindow/size`
+- `mainwindow/fullscreen`
+- `window_status`
+- `view_status`
+- `mainview_status`
+- `screenIndex`
+- `screenBeginIndex`
+- `isScreenEnlarge`
+
+## Practical Recommendation
+
+Start with a runtime experiment matrix before editing the binary.
+
+If Windows-side scaling already produces acceptable results, stop there.
+
+If it does not, the next best path is:
+
+1. isolate `QApplication` creation
+2. isolate main-window show
+3. patch startup before show
+4. neutralize or migrate persisted geometry
+5. validate video panes and multi-monitor layout behavior
+
+## Exit Criteria For A Successful Fix
+
+The fix should only be considered successful if all of the following hold:
+
+1. Main UI is readable at common desktop scales such as 125%, 150%, and 200%.
+2. Camera preview panes are not clipped or distorted.
+3. Multi-window layouts still restore correctly.
+4. Moving the app between monitors does not make it unusably small.
+5. Saved geometry does not trap the app in an old tiny layout after restart.