Re: [PATCH 3/3] winemac: Tell Wine when Cocoa has brought a window to the front.
On Oct 4, 2013, at 12:17 AM, Ken Thomases wrote: --- dlls/winemac.drv/cocoa_app.m| 8 ++-- dlls/winemac.drv/cocoa_window.h | 1 + dlls/winemac.drv/cocoa_window.m | 16 +--- dlls/winemac.drv/event.c| 5 + dlls/winemac.drv/macdrv.h | 1 + dlls/winemac.drv/macdrv_cocoa.h | 1 + dlls/winemac.drv/window.c | 12 7 files changed, 39 insertions(+), 5 deletions(-) 0003-winemac-Tell-Wine-when-Cocoa-has-brought-a-window-to.patch Don't commit this one. It has caused some strange behavior on Mavericks. The other two in the series are OK and useful independently of this one. -Ken
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 00:03, Stefan Dösinger ste...@codeweavers.com wrote:
@@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
wined3d_surface *surface, void *mem
/* Now the surface memory is most up do date. Invalidate drawable
and texture. */
surface_validate_location(surface, SFLAG_INSYSMEM);
surface_invalidate_location(surface, ~SFLAG_INSYSMEM);
-
-/* For client textures OpenGL has to be notified. */
-if (surface-flags SFLAG_CLIENT)
-surface_release_client_storage(surface);
}
else if (surface-flags SFLAG_USERPTR)
{
@@ -2899,9 +2898,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
wined3d_surface *surface, void *mem
surface-resource.allocatedMemory = NULL;
surface-flags = ~(SFLAG_USERPTR | SFLAG_INSYSMEM);
-if (surface-flags SFLAG_CLIENT)
-surface_release_client_storage(surface);
-
surface_prepare_system_memory(surface);
}
What makes this safe, and why is it needed?
BiDi, Unicode 6.3 and Wine.
Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 15:02, Stefan Dösinger stefandoesin...@gmail.com wrote: Client storage only applies to GL textures, which won't be created for sysmem surfaces. I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them.
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 15:28 schrieb Henri Verbeet hverb...@gmail.com: On 4 October 2013 15:02, Stefan Dösinger stefandoesin...@gmail.com wrote: Client storage only applies to GL textures, which won't be created for sysmem surfaces. I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them. No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.)
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger stefandoesin...@gmail.com: No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) Fwiw, the other patches are independent of this patch.
Re: BiDi, Unicode 6.3 and Wine.
While I have no experience contributing code to wine itself so far, BiDi or not, I smell a high-level design choice here. If the new revision to the Unicode algorithm looks superior, my first idea would be to try rebasing the code on that and then explicitly overriding it for Windows quirks. I don't know enough about wine's code or performance issues to advocate when that redirection should take place. I suppose it could be done during compilation and linking, during runtime, or even by just hard-coding and commenting standards and quirks versions in the source. Mine's not the most informed opinion though so I would take it with a grain of salt. -Kyle On 10/04/2013 07:54 AM, Aric Stewart wrote: Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric
Re: [PATCH 2/2] advapi32: Don't cache HKCR if WOW64 redirection flags are set
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://newtestbot.winehq.org/JobDetails.pl?Key=2624 Your paranoid android. === wxppro (32 bit registry) === Timeout
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 15:51, Stefan Dösinger stefandoesin...@gmail.com wrote: No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.)
Re: [PATCH 5/5] wininet: Added InternetLockRequestFile tests.
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://newtestbot.winehq.org/JobDetails.pl?Key=2625 Your paranoid android. === w2008s64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0 === w7pro64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 17:15 schrieb Henri Verbeet hverb...@gmail.com: I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.) My plan is to enforce this in resource_load_location similar to how it's currently done for volumes. That'd be at the end of my surface cleanup patchset though, and it'll need some additional work (downloading a texture to a bigger sysmem surface to handle get_front_buffer_data). I think my surface patches should work ok without the assumption that client storage and user memory are mutually exclusive, so feel free to skip this patch for now. The other 4 patches in this series should work ok. Some later patches in the big patchset need minor adjustments though.
Re: [3/3] ntdll: Add support for FILE_APPEND_DATA to NtWriteFile. Take 2.
Dmitry Timoshkov dmi...@baikal.ru writes:
@@ -979,6 +986,12 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent,
goto done;
}
+if (append_write)
+{
+offset_eof.QuadPart = (LONGLONG)-1; /* FILE_WRITE_TO_END_OF_FILE
*/
+offset = offset_eof;
+}
+
Please add a test for the file position after the write, to show that
this is the correct behavior.
--
Alexandre Julliard
julli...@winehq.org
Re: BiDi, Unicode 6.3 and Wine.
Aric Stewart a...@codeweavers.com writes: Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? I'm not sure that there's any evidence that the existing version is identical to Windows. It's probably just what happened to be the current version when the code was written. As long as it passes reasonable tests, it shouldn't be an issue to use a more recent version. -- Alexandre Julliard julli...@winehq.org
