HiDPI / Scaling window content

[Jordan Johnston]

Hey all,

I'm looking for some pointers on coming up with a hack to better support
HiDPI with wine on my hi-res display (not something that would be submitted
upstream. "hack" indeed)... As you are all probably aware; while you can
adjust DPI in Winecfg, that only affects Windows UI elements  ~ but It does
not help with anything outside of that... I have some apps that are
basically unusable with HiDPI and i've tried multiple solutions, to no
avail. (and setting my resolution to 1440x900 isn't a viable solution
either).

I've been poking around dlls/winex11.drv and I'm wondering if anyone might
have pointers on how some of the scale related stuff works? -- I'm
wondering if it may be possible to hack the x11 code to multiply the scale
of the window contents? (and perhaps, I can then wrap it in an env variable
for use)...

If anyone has any pointers, or if they think something like this could work
-- I'd appreciate your insights (again, I'm just looking for kind of a
one-off hack, not something upstream-able.. I'm sure HiDPI
compatibility-mode will land upstream, at some point (Windows has this)).
While I am familiar with some of Wine's internals - the graphics stack,
window management / x11 code is somewhat alien to me.

Alternatively, i suppose if someone is working on related code and has a
git branch / patchwork available, I'd be open to try that out too.

Thanks, and Happy New Year to you all!

Jordan

[Zhiyi Zhang]

Hi Jordan,

I did work on GDI unaware scaling for HiDPI support about a year ago. The idea is that
winex11.drv scales windows for those applications that doesn't really support HiDPI
but the monitor is using a DPI higher than 96. Basically, winex11.drv hides unscaled
windows and use XDamage and XRender extension to scale the content to a new X window
that will be actually shown.

I have a branch at https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it doesn't work
right now because of the 32on64 work that moves some user32 function into win32u.
Specifically, I need to fix the compilation error in is_dpi_unaware_scaling_required(). But maybe
you can just hack it to return TRUE to make it work. You also need to set DPI in winecfg to 192 for example.
Then things should generally work although there are some bugs need to be fixed. For example,
launching application after wine prefix creation somehow hides the cursor. And it breaks some d3d tests.

Now that 32on64 work has quite down for winex11.drv, I think I am resume this work.
I may revisit this and try to upstream this in the near future.

You might want to try https://github.com/kaueraal/run_scaled as well.

Thanks,
Zhiyi

On 1/5/23 23:32, Jordan Johnston wrote:
> Hey all,
>
> I'm looking for some pointers on coming up with a hack to better support
> HiDPI with wine on my hi-res display (not something that would be submitted
> upstream. "hack" indeed)... As you are all probably aware; while you can
> adjust DPI in Winecfg, that only affects Windows UI elements  ~ but It does
> not help with anything outside of that... I have some apps that are
> basically unusable with HiDPI and i've tried multiple solutions, to no
> avail. (and setting my resolution to 1440x900 isn't a viable solution
> either).
>
> I've been poking around dlls/winex11.drv and I'm wondering if anyone might
> have pointers on how some of the scale related stuff works? -- I'm
> wondering if it may be possible to hack the x11 code to multiply the scale
> of the window contents? (and perhaps, I can then wrap it in an env variable
> for use)...
>
> If anyone has any pointers, or if they think something like this could work
> -- I'd appreciate your insights (again, I'm just looking for kind of a
> one-off hack, not something upstream-able.. I'm sure HiDPI
> compatibility-mode will land upstream, at some point (Windows has this)).
> While I am familiar with some of Wine's internals - the graphics stack,
> window management / x11 code is somewhat alien to me.
>
> Alternatively, i suppose if someone is working on related code and has a
> git branch / patchwork available, I'd be open to try that out too.
>
> Thanks, and Happy New Year to you all!
>
> Jordan

[Jordan Johnston]

Hey Zhiyi,

You mention having originally done this work about a year ago ~ Do you
happen to have an older iteration of the patchwork? - I ask because
currently, I am using a somewhat heavily modified version of Wine-7.5 (also
it also predates the 32on64 work, and various functions being renamed. eg:
NtUser*, props stuff, etc)... An older iteration may actually apply more
cleanly, not require as much to do.

Sticking with an older version of wine due to better performance + avoiding
some regressions for my particular usage.

The bugs sound fairly minor, and your patchwork does seem like what I"m
probably after most likely. I'm super intrigued. -- Please let me know if
you can dig up non-rebased (on upstream/8.0-rc2)  patchwork.. I'd be super
eager to try that out, before trying to rebase/backport to Wine-7.5

Thanks a million!

Jordan

On Thu, Jan 5, 2023 at 9:19 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote:
> Hi Jordan,
>
> I did work on GDI unaware scaling for HiDPI support about a year ago. The
> idea is that
> winex11.drv scales windows for those applications that doesn't really
> support HiDPI
> but the monitor is using a DPI higher than 96. Basically, winex11.drv
> hides unscaled
> windows and use XDamage and XRender extension to scale the content to a
> new X window
> that will be actually shown.
>
> I have a branch at
> https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it doesn't
> work
> right now because of the 32on64 work that moves some user32 function into
> win32u.
> Specifically, I need to fix the compilation error in
> is_dpi_unaware_scaling_required(). But maybe
> you can just hack it to return TRUE to make it work. You also need to set
> DPI in winecfg to 192 for example.
> Then things should generally work although there are some bugs need to be
> fixed. For example,
> launching application after wine prefix creation somehow hides the cursor.
> And it breaks some d3d tests.
>
> Now that 32on64 work has quite down for winex11.drv, I think I am resume
> this work.
> I may revisit this and try to upstream this in the near future.
>
> You might want to try https://github.com/kaueraal/run_scaled as well.
>
> Thanks,
> Zhiyi
>
> On 1/5/23 23:32, Jordan Johnston wrote:
> > Hey all,
> >
> > I'm looking for some pointers on coming up with a hack to better support
> > HiDPI with wine on my hi-res display (not something that would be
> > submitted
> > upstream. "hack" indeed)... As you are all probably aware; while you can
> > adjust DPI in Winecfg, that only affects Windows UI elements  ~ but It
> > does
> > not help with anything outside of that... I have some apps that are
> > basically unusable with HiDPI and i've tried multiple solutions, to no
> > avail. (and setting my resolution to 1440x900 isn't a viable solution
> > either).
> >
> > I've been poking around dlls/winex11.drv and I'm wondering if anyone
> > might
> > have pointers on how some of the scale related stuff works? -- I'm
> > wondering if it may be possible to hack the x11 code to multiply the
> > scale
> > of the window contents? (and perhaps, I can then wrap it in an env
> > variable
> > for use)...
> >
> > If anyone has any pointers, or if they think something like this could
> > work
> > -- I'd appreciate your insights (again, I'm just looking for kind of a
> > one-off hack, not something upstream-able.. I'm sure HiDPI
> > compatibility-mode will land upstream, at some point (Windows has this)).
> > While I am familiar with some of Wine's internals - the graphics stack,
> > window management / x11 code is somewhat alien to me.
> >
> > Alternatively, i suppose if someone is working on related code and has a
> > git branch / patchwork available, I'd be open to try that out too.
> >
> > Thanks, and Happy New Year to you all!
> >
> > Jordan

[Zhiyi Zhang]

Hi Jordan,

Sorry, I didn't keep an older branch. I did find a older version of the patches around April 2022
that should help you to backport these commits to 7.5. I didn't try if these old patches apply cleanly
7.5 or work at all. They should be use only as reference for backporting. What you mostly need is
to replace NtUser* functions to original user32 functions. So the work shouldn't be too difficult.

Thanks,
Zhiyi

On 1/6/23 11:24, Jordan Johnston wrote:
> Hey Zhiyi,
>
> You mention having originally done this work about a year ago ~ Do you
> happen to have an older iteration of the patchwork? - I ask because
> currently, I am using a somewhat heavily modified version of Wine-7.5 (also
> it also predates the 32on64 work, and various functions being renamed. eg:
> NtUser*, props stuff, etc)... An older iteration may actually apply more
> cleanly, not require as much to do.
>
> Sticking with an older version of wine due to better performance + avoiding
> some regressions for my particular usage.
>
> The bugs sound fairly minor, and your patchwork does seem like what I"m
> probably after most likely. I'm super intrigued. -- Please let me know if
> you can dig up non-rebased (on upstream/8.0-rc2)  patchwork.. I'd be super
> eager to try that out, before trying to rebase/backport to Wine-7.5
>
> Thanks a million!
>
> Jordan
>
> On Thu, Jan 5, 2023 at 9:19 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote:
> > Hi Jordan,
> >
> > I did work on GDI unaware scaling for HiDPI support about a year ago. The
> > idea is that
> > winex11.drv scales windows for those applications that doesn't really
> > support HiDPI
> > but the monitor is using a DPI higher than 96. Basically, winex11.drv
> > hides unscaled
> > windows and use XDamage and XRender extension to scale the content to a
> > new X window
> > that will be actually shown.
> >
> > I have a branch at
> > https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it doesn't
> > work
> > right now because of the 32on64 work that moves some user32 function into
> > win32u.
> > Specifically, I need to fix the compilation error in
> > is_dpi_unaware_scaling_required(). But maybe
> > you can just hack it to return TRUE to make it work. You also need to set
> > DPI in winecfg to 192 for example.
> > Then things should generally work although there are some bugs need to be
> > fixed. For example,
> > launching application after wine prefix creation somehow hides the cursor.
> > And it breaks some d3d tests.
> >
> > Now that 32on64 work has quite down for winex11.drv, I think I am resume
> > this work.
> > I may revisit this and try to upstream this in the near future.
> >
> > You might want to try https://github.com/kaueraal/run_scaled as well.
> >
> > Thanks,
> > Zhiyi
> >
> > On 1/5/23 23:32, Jordan Johnston wrote:
> > > Hey all,
> > >
> > > I'm looking for some pointers on coming up with a hack to better support
> > > HiDPI with wine on my hi-res display (not something that would be
> > > submitted
> > > upstream. "hack" indeed)... As you are all probably aware; while you can
> > > adjust DPI in Winecfg, that only affects Windows UI elements  ~ but It
> > > does
> > > not help with anything outside of that... I have some apps that are
> > > basically unusable with HiDPI and i've tried multiple solutions, to no
> > > avail. (and setting my resolution to 1440x900 isn't a viable solution
> > > either).
> > >
> > > I've been poking around dlls/winex11.drv and I'm wondering if anyone
> > > might
> > > have pointers on how some of the scale related stuff works? -- I'm
> > > wondering if it may be possible to hack the x11 code to multiply the
> > > scale
> > > of the window contents? (and perhaps, I can then wrap it in an env
> > > variable
> > > for use)...
> > >
> > > If anyone has any pointers, or if they think something like this could
> > > work
> > > -- I'd appreciate your insights (again, I'm just looking for kind of a
> > > one-off hack, not something upstream-able.. I'm sure HiDPI
> > > compatibility-mode will land upstream, at some point (Windows has this)).
> > > While I am familiar with some of Wine's internals - the graphics stack,
> > > window management / x11 code is somewhat alien to me.
> > >
> > > Alternatively, i suppose if someone is working on related code and has a
> > > git branch / patchwork available, I'd be open to try that out too.
> > >
> > > Thanks, and Happy New Year to you all!
> > >
> > > Jordan

[Jordan Johnston]

Hey Zhiyi,

I'll give these a try. Thanks! ~ this patchset being a bit older, it
probably will line up a bit better with wine-7.5. hopefully, it's mostly
trivial stuff to fixup, as you mention with the NtUser* bits. We shall see
;-) (and actually your current iteration isn't that far off, either).

With any luck, tomorrow I should be able to give this code a spin. I
appreciate you getting back to me. Super helpful and very much appreciated.

Jordan

On Thu, Jan 5, 2023 at 11:23 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote:
> Hi Jordan,
>
> Sorry, I didn't keep an older branch. I did find a older version of the
> patches around April 2022
> that should help you to backport these commits to 7.5. I didn't try if
> these old patches apply cleanly
> 7.5 or work at all. They should be use only as reference for backporting.
> What you mostly need is
> to replace NtUser* functions to original user32 functions. So the work
> shouldn't be too difficult.
>
> Thanks,
> Zhiyi
>
> On 1/6/23 11:24, Jordan Johnston wrote:
> > Hey Zhiyi,
> >
> > You mention having originally done this work about a year ago ~ Do you
> > happen to have an older iteration of the patchwork? - I ask because
> > currently, I am using a somewhat heavily modified version of Wine-7.5
> > (also
> > it also predates the 32on64 work, and various functions being renamed.
> > eg:
> > NtUser*, props stuff, etc)... An older iteration may actually apply more
> > cleanly, not require as much to do.
> >
> > Sticking with an older version of wine due to better performance +
> > avoiding
> > some regressions for my particular usage.
> >
> > The bugs sound fairly minor, and your patchwork does seem like what I"m
> > probably after most likely. I'm super intrigued. -- Please let me know if
> > you can dig up non-rebased (on upstream/8.0-rc2)  patchwork.. I'd be
> > super
> > eager to try that out, before trying to rebase/backport to Wine-7.5
> >
> > Thanks a million!
> >
> > Jordan
> >
> > On Thu, Jan 5, 2023 at 9:19 PM Zhiyi Zhang <zzhang(a)codeweavers.com>
> > wrote:
> > > Hi Jordan,
> > >
> > > I did work on GDI unaware scaling for HiDPI support about a year ago.
> > > The
> > > idea is that
> > > winex11.drv scales windows for those applications that doesn't really
> > > support HiDPI
> > > but the monitor is using a DPI higher than 96. Basically, winex11.drv
> > > hides unscaled
> > > windows and use XDamage and XRender extension to scale the content to a
> > > new X window
> > > that will be actually shown.
> > >
> > > I have a branch at
> > > https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it
> > > doesn't
> > > work
> > > right now because of the 32on64 work that moves some user32 function
> > > into
> > > win32u.
> > > Specifically, I need to fix the compilation error in
> > > is_dpi_unaware_scaling_required(). But maybe
> > > you can just hack it to return TRUE to make it work. You also need to
> > > set
> > > DPI in winecfg to 192 for example.
> > > Then things should generally work although there are some bugs need to
> > > be
> > > fixed. For example,
> > > launching application after wine prefix creation somehow hides the
> > > cursor.
> > > And it breaks some d3d tests.
> > >
> > > Now that 32on64 work has quite down for winex11.drv, I think I am resume
> > > this work.
> > > I may revisit this and try to upstream this in the near future.
> > >
> > > You might want to try https://github.com/kaueraal/run_scaled as well.
> > >
> > > Thanks,
> > > Zhiyi
> > >
> > > On 1/5/23 23:32, Jordan Johnston wrote:
> > > > Hey all,
> > > >
> > > > I'm looking for some pointers on coming up with a hack to better
> > > > support
> > > > HiDPI with wine on my hi-res display (not something that would be
> > > > submitted
> > > > upstream. "hack" indeed)... As you are all probably aware; while you
> > > > can
> > > > adjust DPI in Winecfg, that only affects Windows UI elements  ~ but It
> > > > does
> > > > not help with anything outside of that... I have some apps that are
> > > > basically unusable with HiDPI and i've tried multiple solutions, to no
> > > > avail. (and setting my resolution to 1440x900 isn't a viable solution
> > > > either).
> > > >
> > > > I've been poking around dlls/winex11.drv and I'm wondering if anyone
> > > > might
> > > > have pointers on how some of the scale related stuff works? -- I'm
> > > > wondering if it may be possible to hack the x11 code to multiply the
> > > > scale
> > > > of the window contents? (and perhaps, I can then wrap it in an env
> > > > variable
> > > > for use)...
> > > >
> > > > If anyone has any pointers, or if they think something like this could
> > > > work
> > > > -- I'd appreciate your insights (again, I'm just looking for kind of a
> > > > one-off hack, not something upstream-able.. I'm sure HiDPI
> > > > compatibility-mode will land upstream, at some point (Windows has
> > > > this)).
> > > > While I am familiar with some of Wine's internals - the graphics stack,
> > > > window management / x11 code is somewhat alien to me.
> > > >
> > > > Alternatively, i suppose if someone is working on related code and has
> > > > a
> > > > git branch / patchwork available, I'd be open to try that out too.
> > > >
> > > > Thanks, and Happy New Year to you all!
> > > >
> > > > Jordan

[Stefan Dösinger]

Am Freitag, 6. Jänner 2023, 07:34:10 EAT schrieb Jordan Johnston:
> Sticking with an older version of wine due to better performance +
> avoiding some regressions for my particular usage.

We're generally interested in fixing these kinds of regressions, and also 
performance regressions. Did you file bugs for them? (I see your comment on 
46056; sounds complicated indeed)

If they are highly use-case specific, like you depend on old versions of Linux 
libraries or whatever, we might not be able to address them, still we'd love 
to hear about them.

[Gabriel Ivăncescu]

On 06/01/2023 10:20, Stefan Dösinger wrote:
> Am Freitag, 6. Jänner 2023, 07:34:10 EAT schrieb Jordan Johnston:
> > Sticking with an older version of wine due to better performance +
> > avoiding some regressions for my particular usage.
>
> We're generally interested in fixing these kinds of regressions, and also
> performance regressions. Did you file bugs for them? (I see your comment on
> 46056; sounds complicated indeed)
>
> If they are highly use-case specific, like you depend on old versions of Linux
> libraries or whatever, we might not be able to address them, still we'd love
> to hear about them.

Honestly I hope upstream reconsiders multi-threaded wineserver at some 
point. I know it's single-threaded for stability/simplicity, but it's a 
real bottleneck in some cases.

[Jordan Johnston]

Hey Stefan,
> We're generally interested in fixing these kinds of regressions, and also
> > performance regressions. Did you file bugs for them? (I see your comment
> > on
> > 46056; sounds complicated indeed)

Generally, because I use heavily modified code / fork-of-wine I do not file
bug reports, unless I can reproduce them on vanilla wine (or Staging).
Occasionally, I will reach out to the author of a particular related
patchset, or something like that -- but I don't want to be spamming/filing
invalid bug reports. ( I know the rules ).

Yup, using Wine to run heavily multithreaded proaudio software is a pain /
complicated to do... People have tried to fix it all via Winelib apps /
bridging - but fundamentally, that's not the (full/proper) solution. Wine
itself needs to be patched / fixed, because even with bridges, you will
eventually hit a wall due to limitations in Wine.

I'm sure you remember the Muse Receptor folks? (Wine 1.x era) and the kinds
of hacks they used to employ? (unix pipe synchronization per app, setting
realtime from without wineserver, RT hacks in kernel32, specifically
compiled libs/windows dlls, etc)... or the Wine-RT patch that lives in
Staging? it seems every few years, new ideas/implementations/code rolls out
that helps improve the situation... but much of it never makes it upstream
(often for very valid reasons. eg: too platform-specific. too hackish. etc).

Lots of handy patchwork floating around these days; stuff in Proton.. Zeb's
Esync/Fsync code.. Lots of Remi Bernon's work (LFH, keyed_events+futexes,
and so on).. Some of Torge Matthies' patchwork; especially that killer
multithreaded wineserver patchwork (shmem per thread for
requests/replies)... but I still needed further hacks on his code; dropping
his spinning code (it stalls apps like NI Kontakt), AND I had to set up
these threads' pthread attributes for RT (as his code sets them to NULL)...

This further demonstrates why I can't really file report bugs, to a large
extent... It's kind of a pain, but at least I can run my apps with great
success. That said, maybe when I rebase during Wine-8.x development cycle,
I can test against Wine-Staging and at least do some bug reports, where
applicable.
> > If they are highly use-case specific, like you depend on old versions of
> > Linux
> > libraries or whatever, we might not be able to address them, still we'd
> > love
> > to hear about them.

Highly use-case specific in that I only care about running Proaudio apps
(for personal use). I will make use of any kernel or userland
functionality/advantage to do so. I will employ hacks in Wine, when needed
(even if a bit icky and tricky)... But no, I don't use any kind of
proprietary Winelib apps, no odd-ball compilers or anything like that... I
use Archlinux, a fairly vanilla system, and While I do use a custom kernel,
nothing too exotic: Preempt-rt (6.0.x), some backports from 6.1/2, a few
other bits (stuff that is, or will be upstream)...

For me, the 3 biggest things that I would like to see upstream Wine
implement / support are:

#1 - better handling of Windows Synchronization primitives (this is tricky
to not be platform-specific.)
#2 - Proper mapping of Windows Scheduling to Linux/Unix Scheduling (both
nicess AND RT scheduling)
#3 - Multi-threaded Wineserver (requests, replies and APCs are a huge
bottleneck for single-threaded wineserver)

I have things in place to handle all of these things (to varying degrees),
but it's all very hackish and certainly not suitable for upstream... I
understand a lot of the challenges for upstream here, none of the above are
easy to address - but are all showstopping issues with being able to use
Vanilla Wine, or even Staging.

Honestly I hope upstream reconsiders multi-threaded wineserver at some
> point. I know it's single-threaded for stability/simplicity, but it's a
> real bottleneck in some cases.

I hope so too, Gabriel... Personally, I think Torge's multithreaded
wineserver code demonstrates that there could be some viable solution. ~
I've had ZERO instability using those patches (initial issue aside). ~ I'd
like to see an approach like that, but one that also handles APCs too...
Lots of things can be handled by a single thread, but the server
requests/replies && APCs can't be, at least not when using some heavier
applications. (Ableton Live 11 is a fantastic example, as are certain VSTs).

Cheers, sorry for the lengthy rant guys ;-)

Jordan