Здравствуйте, bnk, Вы писали:

bnk>Когда подключаешь монитор 4к, разница в том как редтерится WinAPI была видна просто невооруженным глазом. Я не знаю почему.

Разница по сравнению чего с чем? Я про виртуальные разрешения спрашивал. Если такая фича есть в АМДшных дравах, ты пробовал это?

bnk>У меня тоже сейчас "обычное" (49" 5K), HiDPI 4K я уже продал

Зачем? оно стоит того?

Здравствуйте, Философ, Вы писали:

bnk>>Когда подключаешь монитор 4к, разница в том как редтерится WinAPI была видна просто невооруженным глазом. Я не знаю почему.

Ф>Разница по сравнению чего с чем? Я про виртуальные разрешения спрашивал. Если такая фича есть в АМДшных дравах, ты пробовал это?

Да. Никакой разницы, просто скорл десктопа.

bnk>>У меня тоже сейчас "обычное" (49" 5K), HiDPI 4K я уже продал

Ф>Зачем? оно стоит того?

Вместо двух мониторов и стоек — один. Еще удобно делать 3-way-merge.

Здравствуйте, пффф, Вы писали:

П>А это кого-то, кроме тебя, беспокоит?

Теоретически эта проблема должна волновать динозавров, которые по какой-то загадочной причине не вымерли, и продолжают писать на MFC. Динозавры при этом должны ещё и о hiDPI парится, т.е. писать для достаточно большой аудитории.

Здравствуйте, bnk, Вы писали:

bnk>У меня не воспроизводились, поэтому и говорю. Возможно специфика приложения

У Вас диалоги статические (загружаемые непосредственно из ресурсов) или динамические (создаваемые/настраиваемые в процессе выполнения)?

Если статические, попробуйте, например, Static Text слева от Edit/Combo Box, чтоб при масштабе 100% текст отображался полностью, и заканчивался где-то в 6-7 точках от следующего элемента. При масштабе 125% такой текст обрезается и в Win7, и в Win8, и в Win10/11, независимо от наличия/отсутствия манифестов поддержки DPI. Если увеличивать интервал до 8-10 точек, то в масштабе 100% образуется слишком широкий зазор.

bnk>просто в манифест прописать что надо

Дык, прописано, не помогает. Пока не было прописано — масштабировало с замыливанием. После прописывания замыливание пропало, но тексты все равно обрезаются. Я так понимаю, это все от кривого пересчета DLU в точки.

Здравствуйте, Философ, Вы писали:

Ф>Причём тут Win32

При том, что этим занимается Win32.

Ф>и зачем всё делать руками?

Например, чтоб не тащить в проект библиотеки "на все случаи жизни" (особенно с "экосистемой", вроде Qt), когда требуется всего-то умеренная адаптация к механизмам, реализованным в ОС.

Ф>Неуж-то Win32 ограничивается GDI?

Окна и диалоги — это уже не чистый GDI, а надстройка над ним.

Что в Win32 есть адекватного для решения описанных проблем?

Здравствуйте, Философ, Вы писали:

Ф>Вы всё ещё про диалоги.

Именно.

Ф>Неужиле для С++ ничего лучше MFC не придумали?

А вот про MFC я ничего не говорил.

Ф>Я бы не стал относить вопрос из сабжа к Win32 — это вопрос про MFC.

А я бы не стал этого утверждать, толком не понимая, что такое MFC.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>В чем разбираться? Для описанной задачи достаточно как-то указать требуемый элемент, и вызывать для него SetWindowPos. Даже в процесс встраиваться не нужно.

А вам надо для своего процесса или для чужого?

Здравствуйте, kov_serg, Вы писали:

_>А вам надо для своего процесса или для чужого?

В первую очередь — для своих, но и для чужих бывает нужно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если статические, попробуйте, например, Static Text слева от Edit/Combo Box, чтоб при масштабе 100% текст отображался полностью, и заканчивался где-то в 6-7 точках от следующего элемента. При масштабе 125% такой текст обрезается и в Win7, и в Win8, и в Win10/11, независимо от наличия/отсутствия манифестов поддержки DPI. Если увеличивать интервал до 8-10 точек, то в масштабе 100% образуется слишком широкий зазор.

ЕМ>Я так понимаю, это все от кривого пересчета DLU в точки.

В DLU задается размер элемента, а GDI рендерит текст по размеру в логических пикселях.
Т.е. не "вписывает" каждую буковку в DLU-шную сетку диалога.
Из-за растризации каждой буквы и связанного с ней округления накапливается разница в длине.
Растризация выполняется в физические пиксели монитора, а не в логические.
Например, линия в 1 логический пиксель при масштабе 200% растризуется в 2 физических пикселя, а при 125% — в один.
Эта проблема GDI особенно сильно вылазила для печати и предварительного просмотра, где масштаб меняется в широких пределах, а также DPI принтера может быть очень разным.

И второй эффект, который может влиять даже сильнее округления при растризации.
Размер шрифта диалога задается в поинтах, которые также привязаны к логическим пикселям в условиях фиксированного DPI.
В структуре LOGFONT за размер отвечает поле lfHeight, где как раз логические пиксели.
И тут просто не хватает точности указания этой высоты. Например, -10 и -12 (в норме она отрицательная).
Если бы они использовали логические пиксели умноженные на 10 хотя бы, то можно было бы задавать -105, например.
Допустим шрифт у нас с высотой -10 на 100%, на 125% он будет -12, а не -12.5 (а это уже 4% разницы).

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В винде, как известно, есть проблема масштабирования диалогов: когда система растягивает диалог для отображения в масштабе больше 100%, размеры элементов приходится округлять, из-за чего они нередко отображаются неправильно (чаще всего пропадают последние буквы static text).

В нормальных графических системах (HTML, Gtk, Tk, Qt...) координаты не гвоздями
прибиваются, а есть так называемая "упаковка", когда есть набор правил описывающих
как будут рстягиваться и позиционироваться элементы. При этом размеры самих элементов
вычисляются динамически, размеры шрифтов заранее не известны и т.п. Обычно всё
выравнивается ну примерно как текст в редакторе wordpad: по какому-либо краю, с
растяжкой или нет... И проблем с тем, что что-то куда-то наезжает -- нет.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В первую очередь — для своих, но и для чужих бывает нужно.

Тогда копайте отсюда

Здравствуйте, Евгений Музыченко, Вы писали:

Ф>>Неужиле для С++ ничего лучше MFC не придумали?
ЕМ>А вот про MFC я ничего не говорил.

А что ещё это может быть, если уж речь про диалоги!? Кроме как в контексте MFC я нигде их больше не встречал.

ЕМ>А я бы не стал этого утверждать, толком не понимая, что такое MFC.

Я понимаю что это: кривая минималистичная надстройка над Win32API. Это единственное место, где я видел диалоги. Я бы сказал, что эта часть API оставлена для обратной совместимости — чтоб старый софт работал. Давно уже это пора пометить как obsolete, а лучше deprecated — чтоб варнинги вываливало.

UPD:

Many Windows APIs do not have an DPI context

Many legacy Windows APIs do not include a DPI or HWND context as part of their interface. As a result, developers often have to do additional work to handle the scaling of any DPI-sensitive information, such as sizes, points, or icons. As an example, developers using LoadIcon must either bitmap stretch loaded icons or use alternate APIs to load correctly-sized icons for the appropriate DPI, such as LoadImage.

https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows?redirectedfrom=MSDN#testing-your-changes

Вот эти самые API я бы и назвал legacy. Более того, если рисовать с помощью direct2d или direct3d, то DPI будет учитываться автоматически. Например, в WPF с этим вообще проблем нет — оно не пиксели использует.

Здравствуйте, Евгений Музыченко, Вы писали:

bnk>>У меня не воспроизводились, поэтому и говорю. Возможно специфика приложения

ЕМ>У Вас диалоги статические (загружаемые непосредственно из ресурсов) или динамические (создаваемые/настраиваемые в процессе выполнения)?

WinForms (.NET)

ЕМ>Если статические, попробуйте, например, Static Text слева от Edit/Combo Box, чтоб при масштабе 100% текст отображался полностью, и заканчивался где-то в 6-7 точках от следующего элемента. При масштабе 125% такой текст обрезается и в Win7, и в Win8, и в Win10/11, независимо от наличия/отсутствия манифестов поддержки DPI. Если увеличивать интервал до 8-10 точек, то в масштабе 100% образуется слишком широкий зазор.

Поставь метки НАД контролами и не парься. Я перевел когда делал локализацию на немецкий. Все равно там нифига не входит.
125% — смешно. На Microsoft Surface 200% стотит чуть ли не по умолчанию.

bnk>>просто в манифест прописать что надо

ЕМ>Дык, прописано, не помогает. Пока не было прописано — масштабировало с замыливанием. После прописывания замыливание пропало, но тексты все равно обрезаются. Я так понимаю, это все от кривого пересчета DLU в точки.

Там размер шрифта диалога еще нужно выставить. DLU от него считается. Я бросил всю эту возню, переделал на Web UI.

Здравствуйте, bnk, Вы писали:

bnk>Там размер шрифта диалога еще нужно выставить. DLU от него считается. Я бросил всю эту возню, переделал на Web UI.

Если изначально был .NET (его можно было), то почему Web UI, а не WPF?

Здравствуйте, Философ, Вы писали:

bnk>>Там размер шрифта диалога еще нужно выставить. DLU от него считается. Я бросил всю эту возню, переделал на Web UI.

Ф>Если изначально был .NET (его можно было), то почему Web UI, а не WPF?

Изначально был старый софт (больше 15 лет). Web UI в основном потому что WPF нормально готовить не умею.

Здравствуйте, bnk, Вы писали:

bnk>Изначально был старый софт (больше 15 лет). Web UI в основном потому что WPF нормально готовить не умею.

А Web-UI можешь нормально готовить? Некоторые думают, что могут.

	сможешь название программы прочитать?

Меня уже слегка достали люди, которые думают, что всё просто и тут всё сделать элементарно — натыкал и работает.

Здравствуйте, fk0, Вы писали:

fk0>В нормальных графических системах (HTML, Gtk, Tk, Qt...) координаты не гвоздями прибиваются, а есть так называемая "упаковка"

Я в курсе, и давно хочу себе такое, но ни разу не видел в изолированном варианте, чтоб только указать, каким образом выравнивать элементы — оно почему-то всегда идет вместе с обширным набором средств чуть не на все случаи жизни, или в виде фреймворка, или завязано на другие библиотеки.

Когда-то я делал небольшую софтину для расстановки дочерних окон в MDI-приложениях по схожим принципам, то ли ее перепилить под это дело...

Здравствуйте, kov_serg, Вы писали:

_>Тогда копайте отсюда

А как мне это поможет в изначально озвученной цели? Как рисовать DPI-aware окна, я примерно представляю, но пока-то задача тупо адаптировать существующие простые диалоги к системному масштабированию.

Здравствуйте, Философ, Вы писали:

bnk>>Изначально был старый софт (больше 15 лет). Web UI в основном потому что WPF нормально готовить не умею.

Ф>[cut=сможешь название программы прочитать?]

Не, не могу, оно замыленное. Это Скайп?

Ф>Меня уже слегка достали люди, которые думают, что всё просто и тут всё сделать элементарно — натыкал и работает.

Ну так так оно и есть — сказал GPT сделай мне красивую страничку, он сделал

Здравствуйте, Философ, Вы писали:

Ф>А что ещё это может быть, если уж речь про диалоги!?

Это может быть чистый хардкор WinAPI.

Ф>Вот эти самые API я бы и назвал legacy.

Так все остальные только через них и работают, с небольшими исключениями.