September 2014 - Wine-Devel

Re: [RFC 0/11] Linux FF: Intro

by Elias Vanderstuyft

On Wed, Sep 3, 2014 at 2:20 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > Hi Elias, > > On Wed, Sep 03, 2014 at 12:36:06PM +0200, Elias Vanderstuyft wrote: >> I'm mailing you to let you know that I'll be unable to create patches >> and corresponding tests for these things, because I'll have no time to >> work on it the coming year. Excuse me for that. >> However, considering the amount of work I put into this, and the fact >> that most bugs in Wine covered by my discussion above are obviously >> clear bugs and some even embarrassing, someone should tackle at least >> part of these problems. >> I would be very glad if someone volunteers in doing so, I will be >> still available if some things are not clear, just mail me. >> > > Thanks for the update. I may try to get to this myself. Also, this > would definitely make a good "newbie" project for someone wanting to > get involved with Wine. You've already done a lot of the hard work, we > just need someone to finish implementing it and make tests and > patches. Thank you very much for your reply, I agree. It's the logical step at around this time, since there's a rising amount of work being done around gaming devices and opensourcing of their corresponding drivers, e.g. Logitech released an opensource spec of the whole FF Protocol of its gaming devices: https://opensource.logitech.com/opensource/index.php/Technical_Information Wine's correct implementation of FF will be crucial in this process to compare performance between Wine and Windows e.g. running Windows racing-sim games, of course our goal is to have superior performance on Linux (this part should be accomplished by using superior kernel drivers). Cheers, Elias

Sept. 7, 2014

Re: [PATCH 4/5] d2d1: Implement initial clipping support.

by Matteo Bruni

2014-09-05 15:50 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > +static BOOL d2d_clip_stack_push(struct d2d_clip_stack *stack, const D2D1_RECT_F *rect) > +{ > + if (stack->current == stack->stack_size - 1) > + { > + D2D1_RECT_F *new_stack; > + unsigned int new_size; > + > + if (stack->stack_size > UINT_MAX / 2) > + return FALSE; > + > + new_size = stack->stack_size * 2; > + if (!(new_stack = HeapReAlloc(GetProcessHeap(), 0, stack->stack, new_size * sizeof(*stack->stack)))) > + return FALSE; > + > + stack->stack = new_stack; > + stack->stack_size = new_size; > + } > + > + stack->stack[stack->current++] = *rect; > + d2d_rect_intersect(&stack->clip_rect, rect); > + > + return TRUE; > +} > + > +static void d2d_clip_stack_pop(struct d2d_clip_stack *stack, unsigned int w, unsigned int h) > +{ > + unsigned int i; > + > + if (!stack->current) > + return; > + > + --stack->current; > + stack->clip_rect.left = 0.0f; > + stack->clip_rect.top = 0.0f; > + stack->clip_rect.right = w; > + stack->clip_rect.bottom = h; > + > + for (i = 0; i < stack->current; ++i) > + { > + d2d_rect_intersect(&stack->clip_rect, &stack->stack[i]); > + } > +} Would it be possible to store the clipped rectangles in the stack instead (so that stack->clip_rect == stack->stack[stack->current] at any given moment)? That way you don't need to recompute clip_rect on each pop.

Sept. 5, 2014

Re: [PATCH 5/5] d2d1/tests: Add a basic clipping tests.

by Henri Verbeet

On 5 September 2014 15:55, Marvin <testbot(a)winehq.org> wrote: > Recreating tests/Makefile > + time make -j2 dlls/d2d1/tests/Makefile > make: *** No rule to make target `dlls/d2d1/tests/Makefile'. Stop. Does the testbot not run tools/make_makefiles perhaps?

Sept. 5, 2014

Re: [PATCH 1/5] widl: Handle aggregate returns in a MSVC compatible way.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)gmail.com> writes: > On 5 September 2014 16:03, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> On 09/05/14 15:50, Henri Verbeet wrote: >>> >>> -static D2D1_COLOR_F STDMETHODCALLTYPE >>> d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface) >>> +static void STDMETHODCALLTYPE >>> d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface, D2D1_COLOR_F >>> *color) >>> { >>> static const D2D1_COLOR_F black = {0.0f, 0.0f, 0.0f, 1.0f}; >>> >>> FIXME("iface %p stub!\n", iface); >>> >>> - return black; >>> + *color = black; >>> } >> >> Shouldn't it return pointer to D2D1_COLOR_F? >> > Not as far as I'm aware. Yes, it should. -- Alexandre Julliard julliard(a)winehq.org

Sept. 5, 2014

Re: [PATCH 1/5] widl: Handle aggregate returns in a MSVC compatible way.

by Henri Verbeet

On 5 September 2014 16:03, Piotr Caban <piotr.caban(a)gmail.com> wrote: > On 09/05/14 15:50, Henri Verbeet wrote: >> >> -static D2D1_COLOR_F STDMETHODCALLTYPE >> d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface) >> +static void STDMETHODCALLTYPE >> d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface, D2D1_COLOR_F >> *color) >> { >> static const D2D1_COLOR_F black = {0.0f, 0.0f, 0.0f, 1.0f}; >> >> FIXME("iface %p stub!\n", iface); >> >> - return black; >> + *color = black; >> } > > Shouldn't it return pointer to D2D1_COLOR_F? > Not as far as I'm aware.

Sept. 5, 2014

Re: (resend)[3/6]dwrite: Implement GetInformationalStrings

by Aric Stewart

On Fri Sep 5 08:53:32 2014, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> http://www.microsoft.com/typography/otspec/name.htm >> >> Name IDs 0-22 are the predefined name ids. >> >> The correlate to DWRITE_INFORMATIONAL_STRING_ID values > > I don't see much correlation in the values... > Well, that is embarrassing. I should have double checked, You are correct. The enum does not correspond to the opentype indexes. Seeing that they where in the same order was not enough. I will rework that patch to be correct. Thanks, -aric

Sept. 5, 2014

Re: [PATCH 1/5] widl: Handle aggregate returns in a MSVC compatible way.

by Piotr Caban

On 09/05/14 15:50, Henri Verbeet wrote: > -static D2D1_COLOR_F STDMETHODCALLTYPE d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface) > +static void STDMETHODCALLTYPE d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface, D2D1_COLOR_F *color) > { > static const D2D1_COLOR_F black = {0.0f, 0.0f, 0.0f, 1.0f}; > > FIXME("iface %p stub!\n", iface); > > - return black; > + *color = black; > } Shouldn't it return pointer to D2D1_COLOR_F?

Sept. 5, 2014

Re: [PATCH 5/5] d2d1/tests: Add a basic clipping tests.

by Marvin

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=8807 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

Sept. 5, 2014

Re: (resend)[3/6]dwrite: Implement GetInformationalStrings

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > http://www.microsoft.com/typography/otspec/name.htm > > Name IDs 0-22 are the predefined name ids. > > The correlate to DWRITE_INFORMATIONAL_STRING_ID values I don't see much correlation in the values... -- Alexandre Julliard julliard(a)winehq.org

Sept. 5, 2014

Re: (resend)[3/6]dwrite: Implement GetInformationalStrings

by Aric Stewart

On Fri Sep 5 08:36:39 2014, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> @@ -53,6 +54,8 @@ struct dwrite_font_data { >> DWRITE_FONT_SIMULATIONS simulations; >> DWRITE_FONT_METRICS metrics; >> >> + IDWriteLocalizedStrings *info_strings[23]; > > Where does this 23 come from? > http://www.microsoft.com/typography/otspec/name.htm Name IDs 0-22 are the predefined name ids. The correlate to DWRITE_INFORMATIONAL_STRING_ID values -aric

Sept. 5, 2014