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

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.