[Wine] Re: How can we improve WNE?
wineforum-user at winehq.org
Wed Apr 8 09:19:56 CDT 2009
> VideoMemorySize I'll agree with you on. If that is left in the
> registry, I won't disagree.
> OffscreenRenderingMode, however, is a fickle beast, and depending on
> the application, fixes tons of problems, or yes, causes random
> crashes. But as I've said, the same can be said for native dlls
> (comctl32/dcom98 are especially bad here). We don't play the
> babysitter for most other settings (only _really_ dangerous ones,
> e.g., changing C:\ to point to a windows install, or running with
> sudo). Changing the OffscreenRenderingMode is no more dangerous than a
> native DLL, and IMHO deserves no special treatment just because it's a
> graphic setting rather than a DLL setting.
Can already be done. May not be easiest thing to do, but can already be done via regedit.
At least native DLLs are more predictable than changing OffscreenRenderingMode. They're also more important to support, as there are obvious deficiencies in Wine (e.g. gdiplus and d3dx9_##) that currently can't be resolved without native DLLs, due to completely missing implementations. Before you argue that there's no way to resolve some games without OffscreenRenderingMode, it's not quite the same category. In theory, with enough work, any OffscreenRenderingMode would work with any game. In practice, we know this is not the case.
> Long story short, I see a lot of hypocrisy in the argument that
> "changing graphics settings can cause crashes/bugs, we can't allow
> that" and "here, change DLL load order to native, even for native Wine
> programs. No warning needed, you're smart enough to figure that out."
It's not the easiest or most obvious thing to force a DLL override to native in winecfg (not even obvious to make it native,builtin). We also say "here, change the registry settings for advanced Direct3D and OpenGL stuff manually, you're smart enough to figure it out with the UsefulRegistryKeys page on the wiki" already. So, the argument doesn't seem hypocritical to me. If anything, it's *easier* to change the settings according to UsefulRegistryKeys than it is to set native DLLs, just due to the wording in the Libraries tab.
> Winecfg exists to make changing Wine settings easier on users. There
> is _nothing_ in winecfg that can't be done in the registry or
> elsewhere (the drives must be done via terminal/file manager).
You're absolutely correct! Do you know what that means? There is *no reason at all* to provide "advanced" settings in winecfg. Users who need them can use regedit, just like they'd have to do on Windows for equally advanced settings.
> If we want to protect users from changing Wine,
We don't. You already said you can change this stuff via the registry. It just doesn't need to be made any easier; the settings simply aren't that reliable or common enough to go in winecfg.
> then remove winecfg.
Which won't happen, because then there would be no simple way to change things like audio drivers, reported Windows version, drive type configurations, DPI settings (you pointed out earlier that there is a preview for the DPI setting, can't have a preview via regedit!), shader settings, and the "Desktop Integration" directory settings. Sure, you can change all those via registry too (since the settings are stored in the registry) but these are settings that are common to (virtually) every single application run in wine. The advanced graphics settings are only required for a small handful of games, and are more likely to cause problems than solve them.
> that's done, there _is no_ merit in saying that we shouldn't allow
> changing graphics settings. Again, I _know_ that progress is close to
> it not being needed. The same was said with the ddraw rewrite, which,
> even though it is nearly 3 years old, still has regressions. Winecfg
> is there to make adjustments easier on users, graphics tweaks are
> typically needed for games, and allowing changing those settings makes
Wine already does very well not requiring graphics tweaks for games. In fact, graphics tweaks are not required for 99% of the games I've *ever* tried to run in Wine (one game requires ddraw renderer to be set to opengl, another looks marginally better if OffscreenRendererMode is set to fbo). Again, I question the suggestion that these settings are common enough that they should be available as settings in winecfg.
> Working in #winehq/the forums a lot, I've got a bit less of a
> developer mentality.
As a regular supporter in #winehq, I do *not* want to see a new wave of users going "my app is broken" where the solution is "don't use those advanced graphics settings; hit the reset button". That is my main concern with making it easy to change values that, in general, should never be changed.
> While I see both sides of the argument, I get the
> feeling many developers forget that users are using Wine to get work
> done/play their game/use their application. What's in the future is
> unimportant. They simply want to use it now. If we want to encourage
> that, like already do by including winecfg, then there's no reason we
> shouldn't add these graphics tweaks. If not, then remove winecfg, or
> even remove the tweaks that can be dangerous, to eliminate the
What you're talking about is essentially a quick hack to fix a handful of problems, hiding the bugs instead of fixing them. Wine devs don't like doing that.
More information about the wine-users