[prev in list] [next in list] [prev in thread] [next in thread]
List: wine-devel
Subject: Re: HiDPI / Scaling window content
From: Jordan Johnston <johnstonljordan () gmail ! com>
Date: 2023-01-06 16:55:48
Message-ID: CAKgnZ5yo8swGoWTkgRgSvGtQFPoSKLEBee80NjiRgRZ+A3R2Bg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<div dir="ltr">Hey Stefan,<br><div><br><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> > We're generally interested in fixing \
these kinds of regressions, and also<br> > performance regressions. Did you file \
bugs for them? (I see your comment on<br> > 46056; sounds complicated \
indeed)<br></blockquote><div><br></div><div>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 \
).<br></div><div><br></div><div>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. <br></div><div><br></div><div>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).<br><br></div><div>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)...<br></div><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div> > If they are highly use-case specific, \
like you depend on old versions of Linux<br> > libraries or whatever, we might not \
be able to address them, still we'd love<br> > to hear about \
them.<br></div></blockquote><div> </div><div><div>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)...<br><br></div><div>For me, the 3 biggest things that I \
would like to see upstream Wine implement / support are:<br><br></div><div>#1 - \
better handling of Windows Synchronization primitives (this is tricky to not be \
platform-specific.)</div><div>#2 - Proper mapping of Windows Scheduling to Linux/Unix \
Scheduling (both nicess AND RT scheduling)<br></div><div>#3 - Multi-threaded \
Wineserver (requests, replies and APCs are a huge bottleneck for single-threaded \
wineserver)<br></div><div><br></div><div>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.<br></div><div><br></div></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div>
Honestly I hope upstream reconsiders multi-threaded wineserver at some <br>
point. I know it's single-threaded for stability/simplicity, but it's a <br>
real bottleneck in some cases.<br></div></blockquote><div><br></div><div>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).<br></div><div><br></div><div>Cheers, sorry \
for the lengthy rant guys ;-)<br><br></div><div>Jordan<br></div><div> \
</div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic