wine-devel August 2013

74 participants
203 discussions

Re: [PATCH 4/6] wined3d: Enforce volume mapping restrictions

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > --- > dlls/wined3d/volume.c | 7 +++++++ > 1 file changed, 7 insertions(+) It breaks the tests: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so volume.c && touch volume.ok volume.c:187: Test succeeded inside todo block: D3DXLoadVolumeFromMemory returned 0x8876086c, expected 0x8876086c make: *** [volume.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

10 years, 8 months

Wiki is down

by Rosanne DiMesio

I'm getting an "Unable to connect" message from Firefox and "Connection closed by remote server" from Opera. -- Rosanne DiMesio <dimesio(a)earthlink.net>

10 years, 8 months

winmm: Increase mmdevapi buffer sizes.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum argued: -/* buffer size = 10 * 100000 (100 ns) = 0.1 seconds */ +/* buffer size = 100 * 100000 (100 ns) = 1 second */ >The tiny buffer size caused audio capture glitches on OSX, where the OS >often returns audio in half-second chunks. That may be good enough for winmm, but that does not solve the problem in general. Since Vista, apps can access mmdevapi directly, thus they won't benefit from this increase in winmm buffer size. I believe that instead and in general, Wine should decouple WinAPI usage from idiosyncrasies of the underlying OS. IOW, apps requesting a mmdevapi capture buffer of a size that typically works on native should work in Wine too. If 100-200ms is that typical size, then it must be made to work with Wine's back-ends, perhaps by using a hidden buffer of at least 1s *internally* in winecoreaudio (and presumably winealsa for when Jack is in use). Somehow, Wine must bridge the impedance mismatch between native's 100-200ms buffers and the observed >0.5s buffer requirements on OSX. BTW, does that imply that input signal processing will see data with 0.5s latency on OSX? Would there be a 0.5s delay in chat applications? Regards, Jörg Höhle

10 years, 8 months

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes

by Henri Verbeet

On 22 August 2013 23:22, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -145,6 +158,9 @@ static DWORD volume_access_from_location(DWORD location) > case WINED3D_LOCATION_TEXTURE_RGB: > return WINED3D_RESOURCE_ACCESS_GPU; > > + case WINED3D_LOCATION_BUFFER: > + return WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_GPU; > + Why does loading into a PBO require CPU access? > + case WINED3D_LOCATION_BUFFER: > + if (!volume->pbo || !(volume->flags & WINED3D_VFLAG_PBO)) > + { > + ERR("Trying to load WINED3D_LOCATION_BUFFER without setting it up first.\n"); > + return; > + } I think there should never be a PBO without WINED3D_VFLAG_PBO being set. There's also something to be said for leaving out the return, since that would at least in theory allow the compiler to drop the extra checks when compiled without debug messages. That probably applies to ERRs in general, since they're either never supposed to happen, or not supposed to be an ERR. > +/* Context activation is done by the caller. */ > +static void wined3d_volume_prepare_pbo(struct wined3d_volume *volume, struct wined3d_context *context) > +{ > + const struct wined3d_gl_info *gl_info = context->gl_info; > + > + if (volume->pbo) > + return; > + > + GL_EXTCALL(glGenBuffersARB(1, &volume->pbo)); > + checkGLcall("glGenBuffersARB(1, &volume->pbo)"); > + GL_EXTCALL(glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->pbo)); > + checkGLcall("glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->pbo)"); > + GL_EXTCALL(glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->resource.size, NULL, GL_STREAM_DRAW_ARB)); > + checkGLcall("glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->resource.size, NULL, GL_STREAM_DRAW_ARB"); > + GL_EXTCALL(glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, 0)); > + checkGLcall("glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, 0)"); > + > + TRACE("Created PBO %u for volume %p.\n", volume->pbo, volume); > +} I think one checkGLcall() per function is enough in general. That's even more true these days with ARB_debug_output that will usually give more specific error messages than checkGLcall() anyway. Applies to a couple of other places as well.

10 years, 8 months

Re: Permissions bug with Acrobat X Standard

by Alexey Loukianov

Neil, thanks for reporting. Could you please re-report this bug to a place where reports should be posted - i.e. to Wine's Bugzilla which could be found at http://bugs.winehq.com/ ? Thanks in advance. --- Best regards, Alexey Loukianov HPC support and maintenance engineer, RSC Technologies http://rscgroup.ru/en/

10 years, 8 months

Re: comsvcs: Add dll comsvcs (try 3)

by Nikolay Sivov

On 8/23/2013 13:18, Alistair Leslie-Hughes wrote: > Hi, > Fix build issue > > +#include "rpcproxy.h" I don't think you need this. > +HINSTANCE COMSVCS_hInstance = NULL; This should be static (and without initializer after that).

10 years, 8 months

Re: server: Store full sized completion information on the server side.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -152,7 +152,7 @@ struct completion *get_completion_obj( struct process *process, obj_handle_t han > } > > void add_completion( struct completion *completion, apc_param_t ckey, apc_param_t cvalue, > - unsigned int status, unsigned int information ) > + apc_param_t information, unsigned int status ) There's no reason to change the parameter order. That's only adding noise to the patch, and potential bugs. -- Alexandre Julliard julliard(a)winehq.org

10 years, 8 months

Request to delete some attachments

by Ken Sharp

Could a Bugzilla admin please delete the attachments in http://bugs.winehq.org/show_bug.cgi?id=24867 ? I don't know if metatester.exe can be freely distributed.

10 years, 8 months

Re: wined3d: Recognize Nvidia GeForce GTX 770

by Henri Verbeet

On 22 August 2013 03:31, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > + {"GTX 770", CARD_NVIDIA_GEFORCE_GTX770}, /* Geforce 700 - highend */ > {"GTX 770M", CARD_NVIDIA_GEFORCE_GTX770M}, /* Geforce 700 - midend high mobile */ That doesn't work, it will always match "GTX 770" now, and never "GTX 770M".

10 years, 8 months

Re: [PATCH] winemac.drv: Support the public UTF-16 type for Unicode text. (try 2)

by Ken Thomases

On Aug 22, 2013, at 12:07 AM, Charles Davis wrote: > Try 2: Eliminiate dead store. Sort export functions by name. Looks OK to me. -Ken

10 years, 8 months

← Newer
1
...
4
5
6
7
8
9
10
...
21
Older →

Jump to page:

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 August 2013