152 lines
No EOL
4.6 KiB
Markdown
152 lines
No EOL
4.6 KiB
Markdown
# 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. |