wine-devel April 2017

wine-devel@winehq.org

67 participants
225 discussions

Re: [v3 PATCH 1/2] wined3d: Add dirty region tracking.
by Henri Verbeet 23 Apr '17

23 Apr '17

On 20 April 2017 at 16:01, Masanori Kakura <kakurasan(a)gmail.com> wrote: > v2 - Use array > - Regions are stored in struct wined3d_texture > - Reuse old region if possible > v3 - Update Wine d3d8 test > - Get rid of "Ignoring dirty_region" FIXME in wined3d_texture_add_dirty_region() > > Signed-off-by: Masanori Kakura <kakurasan(a)gmail.com> > --- > dlls/d3d8/tests/visual.c | 10 ++--- > dlls/d3d9/tests/visual.c | 10 ++--- > dlls/wined3d/cs.c | 51 +++++++++++++++++++++- > dlls/wined3d/device.c | 6 +++ > dlls/wined3d/texture.c | 97 ++++++++++++++++++++++++++++++++++++++++-- > dlls/wined3d/wined3d_private.h | 9 +++- > 6 files changed, 167 insertions(+), 16 deletions(-) > Do you have any thoughts on the interactions with the resource location management?

2 2

Re: [PATCH 5/5] ddraw/tests: Introduce a helper function to create windows.
by Marvin 23 Apr '17

23 Apr '17

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=30354 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:3724: Test failed: Lit quad without normals has color 0x00ff0000, expected 0x00000000. ddraw7.c:3728: Test failed: Lit quad with normals has color 0x00ff0000, expected 0x00000000. ddraw7.c:3752: Test failed: Lit quad with light has color 0x00ff00ff. ddraw7.c:3752: Test failed: Lit quad with singular world matrix has color 0x00ff00ff. ddraw7.c:3752: Test failed: Lit quad with transformation matrix has color 0x00ff00ff. ddraw7.c:3752: Test failed: Lit quad with non-affine matrix has color 0x00ff0000.

1 0

Slow emulation of StretchBlt
by andrea 22 Apr '17

22 Apr '17

Hi, I am looking at the performance of AppleWin (a 32 bit app) in Wine and have come across this function StretchBlt which seems to be much slower in Wine that in Windows 10. The call looks like this StretchBlt( hFrameDC, xdest, ydest, wdest, hdest, g_hDeviceDC, xSrc, ySrc, FRAMEBUFFER_BORDERLESS_W, FRAMEBUFFER_BORDERLESS_H, SRCCOPY); With typical values xdest 0 int ydest 0 int wdest 1120 int hdest 768 int xSrc 22 int ySrc 17 int #define FRAMEBUFFER_BORDERLESS_W 560 #define FRAMEBUFFER_BORDERLESS_H 384 In Wine they take 20x the time in Windows 10 (running inside a VirtualBox). The consequence is CPU utilisation 20x higher in Wine than Windows. I am running wine 2.5 in a 64 bit Fedora 25 machine. Does this ring any bell? Andrea

5 6

Debian Download Page
by Stefan Leichter 22 Apr '17

22 Apr '17

Hi, when following the instruction at https://wiki.winehq.org/Debian the command "sudo apt-get update" gives me the error: -------------------------------------------------------------------- W: GPG error: https://dl.winehq.org jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 818A435C5FCBF54A -------------------------------------------------------------------- Does anyone else see the same error? Minor item: Any reason that "wine-stable" is not listed on the download page? Regards Stefan

2 2

Linux desktop integration: Fill StartupWMClass in .desktop menu entries
by Eike Hein 22 Apr '17

22 Apr '17

Hi, I maintain the taskbar in Plasma 5 and would like to poke folks about a desktop integration pain point we (and our friends at other DEs) face with apps run via wine. Here's the relevant ticket: https://bugs.winehq.org/show_bug.cgi?id=32699 Let me give some broader context on this. Modern DEs have a swath of UX going on that relies on being able to identify the application owning a particular window in the windowing system. "Identify the application" in practice means "map the window to a .desktop file installed in the menu file system". We want to do this because: a) Many a taskbar/dock-like UI tries to form a smooth life cycle across "launcher button", "startup notification" and "window button(s)". For each of those we need to work out the app they are associated with to be able to match them up. If it fails, ugly things like co-existing task buttons or missing startup throbbers and similar happen. b) UI these days tends to prefer to load assets such as app icons via the values defined in .desktop files instead of using the window icon, to ensure consistent results (apps may load icon assets differently from the shell, leading to asset quality issues, inconsistent theming, the icon changing between the lifecycle states mentioned in 'a', etc.) Plus the Wayland windowing system we're all migrating towards currently doesn'ㅅ have window icons. c) DEs do things like track app starts/quits for things like "Most used apps" launcher lists. To match a window to a .desktop file we rely on window and process metadata. On X11, there's the WM_CLASS window property: https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS Ideally, the second part of a X11 window's WM_CLASS matches the name of a .desktop file installed on the system. Failing that, it matches the value of StartupWMClass in that .desktop file (this is the key part I'll get back to soon). Here's some more documentation by our friends at Gnome on this standard scheme: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased (Look for WM_CLASS / StartupWMClass.) In practice, we pull many other tricks to cope with broken meta data. We try to match things by names, we grab process command lines from /proc and check them against Exec keys in .desktop files in complicated ways, ... it's a multi-page heuristic, and other DEs (Unity via bamf, Gnome Shell via iirc ShellWindowTracker) have equivalent code. Something Gnome does that we don't do (because I think it's brittle) is to store the name of the .desktop file an app was launched with as a private window hint on the next window that comes up (which then doesn't work when the app was launched from CLI instead of shell UI). None of these things currently allow us to handle wine very well. As of now (perhaps thanks to the patch mentioned in the linked ticket), wine sets WM_CLASS to the executable name of the app, e.g. "Notepad.exe". But the .desktop files it generates don't match this by name, and they don't contain a StartupWMClass key. The process command line is the Windows-like path to the .exe, which we also can't easily match up to the complicated Exec values in wine's .desktop files. (Aside: On Wayland, there's a more modern version of this: Windows have an appid property, which should be set to a .desktop file name. I don't know what the status of Wayland support in wine is -- currently the wine clients we encounter run over Xwayland, so we're back to WM_CLASS. We hope wine will set this property correctly when the time comes, or we're happy to work with you guys to find a way to support wine.) Long story short ... could this be picked up? The goal must be to have either .desktop file names or their StartupWMClass values match whatever is set as WM_CLASS. Currently, the easiest fix would be to set StartupWMClass to the executable name set as WM_CLASS. I assume the .desktop file generator has access to this, as the .lnk file referred to by Exec should presumably contain the name of the executable to be launched. Cheers, Eike

2 2

Re: [PATCH 3/4] d3d9/tests: Accept alpha channel differences in shadow_test.
by Marvin 21 Apr '17

21 Apr '17

2 1

Re: [PATCH 1/4] ddraw/tests: Don't use DDBLT_COLORFILL in test_flip (v2).
by Marvin 21 Apr '17

21 Apr '17

2 1

Re: [Tools v2] winetest/dissect: Check the build id and get its details in one Git call.
by Alexandre Julliard 21 Apr '17

21 Apr '17

Francois Gouget <fgouget(a)codeweavers.com> writes: > get_build_info() only returns an empty subject if the commit does not > exist. It may still exist but not be a proper commit SHA-1. I'm not sure it's a good idea to relax that test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/8] d3dx9: Support parameters sharing in effect.
by Matteo Bruni 21 Apr '17

21 Apr '17

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/d3dx9_private.h | 11 ++- > dlls/d3dx9_36/effect.c | 197 +++++++++++++++++++++++++++++++++++++++++- > dlls/d3dx9_36/tests/effect.c | 17 ++-- > 3 files changed, 211 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index da4564d..d6d4280 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -215,15 +215,22 @@ struct d3dx_parameter > struct d3dx_parameter *annotations; > struct d3dx_parameter *members; > > - struct d3dx_parameter *referenced_param; > struct d3dx_param_eval *param_eval; > > struct d3dx_parameter *top_level_param; > + union > + { > + struct d3dx_parameter *referenced_param; > + struct d3dx_parameter *shared_param; > + }; > + LONG shared_refcount; > }; I think you mentioned this before but it shouldn't be necessary to store the whole parameter structure in the pool. I guess it could be improved after the fact but it shouldn't be too complicated to do it right away. Probably it could just be shared_param_list[] from patch 8/8 and shared_refcount (which at that point won't need to be in struct d3dx_parameter anymore), in addition to data. You could access the other parameter fields through shared_param_list[0]. > +static void d3dx_pool_sync_shared_parameter(struct ID3DXEffectPoolImpl *pool, struct d3dx_parameter *param) > +{ > + unsigned int i, free_entry_index; > + LONG new_refcount; > + > + if (!(param->flags & PARAMETER_FLAG_SHARED) || !pool > + || is_param_type_sampler(param->type)) > + return; > + > + free_entry_index = pool->parameter_count; > + for (i = 0; i < pool->parameter_count; ++i) > + { > + if (!pool->parameters[i]->shared_refcount) > + free_entry_index = i; > + else if (is_same_parameter(param, pool->parameters[i])) > + break; > + } > + if (i == pool->parameter_count) > + { > + i = free_entry_index; > + if (i >= pool->table_size) > + { > + struct d3dx_parameter ** new_alloc; No whitespace after "**", please. > + else > + { > + new_size = pool->table_size * 2; > + new_alloc = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, pool->parameters, > + sizeof(*pool->parameters) * new_size); > + if (!new_alloc) > + { > + ERR("Out of memory.\n"); > + return; > + } > + } > + pool->parameters = new_alloc; > + pool->table_size = new_size; > + } > + pool->parameters[i] = HeapAlloc(GetProcessHeap(), > + HEAP_ZERO_MEMORY, sizeof(*pool->parameters[i])); > + copy_parameter_structure(param, pool->parameters[i], NULL, FALSE); > + param_set_data_pointer(pool->parameters[i], (unsigned char *)param->data, FALSE, FALSE); > + if (i == pool->parameter_count) > + pool->parameter_count++; > + } I don't think this works. HeapReAlloc might move the memory block and that would break the preexisting effects using the pool (and also the previous parameters of the new effect). HEAP_REALLOC_IN_PLACE_ONLY would avoid that but it also makes it easier for the reallocation to fail. I see two ways to fix this: - refresh all the parameters of the effects that are in the pool when you have to reallocate (shared_param_list[] might help here) - allocate the memory in chunks, keeping an array (or list) of chunks which you allocate (but never resize) as needed

2 1

Re: [Tools v2] winetest: Get rid of $gitdir.
by Alexandre Julliard 21 Apr '17

21 Apr '17

Francois Gouget <fgouget(a)codeweavers.com> writes: > WineHQ appears to use /home/winehq/opt/source/git/wine.git as the Wine > checkout directory. After this patch the scripts will use > $workdir/wine.git so this should most likely symlink to the above > location. I'm not sure that's an improvement. > However any non-official site will actually need write access to it from > the scripts to ensure that wine.git is up to date before processing > reports. Otherwise the reports risk being rejected due to the not yet > known commit id. This could still work with a placement in tools/winehq: > one would just have to symlink that to a writable location but it does > imply placing it in $workdir may make more sense. I don't think it makes sense to put it in the website directory, it's not meant to be accessed from the web. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2017