5 Commits
Author SHA1 Message Date
ew8bakandClaude Opus 4.8 388687d684 fix(macos): масштаб канвы берём у окна контрола, а не у главного экрана
backingScaleFactor главного экрана врёт, когда окно лежит на другом
мониторе. Спрашиваем масштаб у NSWindow того NSView, которому принадлежит
паинтбокс: это ровно то число, в котором Cocoa рисует эту канву, и оно
меняется само при перетаскивании окна между мониторами.

Objective-C по-прежнему живёт только в MacScale; наружу торчит
кроссплатформенная GetControlScale, которая на Windows/Linux сворачивается
в Result := 1.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-09 21:20:53 +03:00
ew8bakandClaude Opus 4.8 fd8769898a fix(macos): S-метр, линейка и зумбар больше не мылятся на Retina
Cocoa рисует канву в физических пикселях, TBitmap всегда 1x, поэтому кадр,
собранный в offscreen-битмап логического размера, растягивался вдвое.

PlatformUtils.GetScreenScale возвращает 2 на Retina и 1 на остальных
платформах. Масштаб — обычная переменная, а не условная компиляция: на
Windows/Linux умножение на 1 даёт прежние числа, а на канву кадр кладётся
через Draw, как и раньше (StretchDraw только при масштабе > 1).

В SMeterView, RulerView и PanZoomBar битмап растёт в S раз, пиксельные
константы, размеры шрифтов и толщина пера умножаются на S. Перо важно
отдельно: иначе на Retina все риски стали бы вдвое тоньше.

RulerView кэширует битмап, поэтому смена масштаба сбрасывает кэш.
PanZoomBar.ThumbGeom получил параметр AScale: отрисовка зовёт его с
физической шириной, хит-тест мыши — с логической, код мыши не менялся.

Objective-C изолирован в MacScale.pas: {$MODESWITCH OBJECTIVEC1} несовместим
с {$MODE Delphi}, а DWARF-3 (-gw3, Debug-режим lazbuild) роняет FPC 3.2.4 с
internal error 200609171 на любых Objective-C типах — отсюда {$DEBUGINFO OFF}.

Замер после правки: 37.5% CPU против 38% базовых, отрисовка этих трёх
элементов ниже уровня шума в профиле.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-09 19:09:53 +03:00
ew8bakandClaude Opus 4.8 5c17fdcb7e fix: center ruler labels vertically (short ticks + TextHeight centering)
After tying the ruler font to the ruler height, the labels (drawn at a
fixed H/2-1 top) sat below center because the taller font extended
downward. Shorten the ticks (major H*0.34, minor H*0.20) and center the
label in the area beneath them using TextHeight, so the digits are
vertically centered at any DPI. Applies to both the normal grid and the
FM-step grid branch.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 21:33:19 +03:00
ew8bakandClaude Opus 4.8 fd85b532ee fix: ruler text scales with DPI (font height tied to ruler height)
The ruler drew labels at a fixed Font.Size := 7, so on Windows display
scaling (125/150/200%) the text no longer matched the DPI-scaled ruler
height — labels came out too small or clipped. Tie the font height to
the ruler height (-Max(8, Round(H*0.45))) so labels scale with DPI,
matching the approach used by the new bandplan overlay.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 21:04:44 +03:00
ew8bakandClaude Sonnet 4.6 d99c19ec9a Split SpectrumView into WaterfallView, SMeterView, RulerView modules
TSpectrumView remains the public facade for MainForm; waterfall, S-meter,
and ruler rendering are now in isolated units. Dead code removed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-22 11:16:55 +03:00