Re: [2/2] gdiplus: Add 8bpp to the list of supported formats.

2012-07-17 Thread Vincent Povirk
>> > +&GUID_WICPixelFormat8bppGray,
>>
>> This will give you a halftone palette instead of a grayscale palette,
>> unless you add special handling for that format.
>
> That's fine for the time being.

Currently, the images should render correctly because WIC converts
them to 32-bit RGBA, so rendering of TIFF images in this format will
regress.




Re: [2/2] gdiplus: Add 8bpp to the list of supported formats.

2012-07-17 Thread Dmitry Timoshkov
Vincent Povirk  wrote:

> > +&GUID_WICPixelFormat8bppGray,
> 
> This will give you a halftone palette instead of a grayscale palette,
> unless you add special handling for that format.

That's fine for the time being.

-- 
Dmitry.




Re: [2/2] gdiplus: Add 8bpp to the list of supported formats.

2012-07-17 Thread Vincent Povirk
> +&GUID_WICPixelFormat8bppGray,

This will give you a halftone palette instead of a grayscale palette,
unless you add special handling for that format.




Re: [PATCH 5/5] d3dcompiler: Implement basic expressions parsing.

2012-07-17 Thread Matteo Bruni
2012/7/17 Stefan Dösinger :
> Am Montag, 16. Juli 2012, 20:39:23 schrieb Matteo Bruni:
>> +HLSL_IR_BINOP_MUL,
>> ...
>> +HLSL_IR_BINOP_DOT,
> HLSL has 3 somewhat related multiplication operations: "*", "mul" and "dot".
> Dot is fairly straightforward, but "*" and "mul" have subtle differences. I
> recommend to write tests to find out the exact details, but as far as I
> remember "float4 * float4" gives you a float4 with a component-wise
> multiplication, whereas mul(float, float) returns a scalar like the dot
> product. "float4x4 * float4" is an error, but mul(float4x4, float4) performs a
> matrix-vector multiplication and returns a float4.
>

Indeed this is not very clear, but with HLSL_IR_BINOP_MUL I mean the
translation of the "*" operator, while I'm planning to handle the
mul() intrinsic with some code translating that into a bunch of MULs,
ADDs and DOTs depending on the specific data types. mul() is
apparently documented quite okay in MSDN but I know I'll have to test
all of that anyway...

>> +static struct hlsl_type *expr_common_type(struct hlsl_type *t1, struct
>> hlsl_type *t2,
>> +struct source_location *loc)
> This type inference system might be a bit too limited, you have to take the
> operation into account. e.g. a dot(float3, float4) returns a scalar and
> crs(float4, float4) returns a float3.
>

Yeah, you're right, I'll need to take into account the operation in
some cases, I consider this as a first "approximation". However I was
planning to handle the "intrinsic function parameters / return value"
case you mention in a different way, i.e. by explicitly generating all
the intrinsic functions prototypes, with all the data type
combinations allowed, and letting the (currently missing) "overloaded
functions type checker/dispatcher" deal with the data types.

Not that I have written that code yet, so it may reveal to be a bad
idea in the end. Stay tuned...




Re: include: fix mingw64 build

2012-07-17 Thread Nicolas Le Cam
2012/7/17 Jacek Caban :
> On 07/15/12 14:21, Nicolas Le Cam wrote:
>> Hi Jacek,
>>
>> Could it be backported into stable 2.x ? This will allow distros to
>> package it with the next stable release of mingw-w64.
>
> I've just committed it to 2.x branch. It's up to distros now to update
> packages.
>
> Jacek

Thanks a lot Jacek !


-- 
Nicolas Le Cam




Re: include: fix mingw64 build

2012-07-17 Thread Jacek Caban
On 07/15/12 14:21, Nicolas Le Cam wrote:
> Hi Jacek,
>
> Could it be backported into stable 2.x ? This will allow distros to
> package it with the next stable release of mingw-w64.

I've just committed it to 2.x branch. It's up to distros now to update
packages.

Jacek




Re: [PATCH 5/5] d3dcompiler: Implement basic expressions parsing.

2012-07-17 Thread Stefan Dösinger
Am Montag, 16. Juli 2012, 20:39:23 schrieb Matteo Bruni:
> +HLSL_IR_BINOP_MUL,
> ...
> +HLSL_IR_BINOP_DOT,
HLSL has 3 somewhat related multiplication operations: "*", "mul" and "dot". 
Dot is fairly straightforward, but "*" and "mul" have subtle differences. I 
recommend to write tests to find out the exact details, but as far as I 
remember "float4 * float4" gives you a float4 with a component-wise 
multiplication, whereas mul(float, float) returns a scalar like the dot 
product. "float4x4 * float4" is an error, but mul(float4x4, float4) performs a 
matrix-vector multiplication and returns a float4.

> +static struct hlsl_type *expr_common_type(struct hlsl_type *t1, struct
> hlsl_type *t2,
> +struct source_location *loc)
This type inference system might be a bit too limited, you have to take the 
operation into account. e.g. a dot(float3, float4) returns a scalar and 
crs(float4, float4) returns a float3.


signature.asc
Description: This is a digitally signed message part.



Re: riched20: Avoid uninitialized field in STGMEDIUM structure (LLVM/Clang).

2012-07-17 Thread Alexandre Julliard
Nicolas Le Cam  writes:

> @@ -1098,6 +1098,8 @@ static BOOL ME_RTFInsertOleObject(RTF_Info *info, 
> HENHMETAFILE hemf, HBITMAP hbm
>BOOLret = FALSE;
>DWORD   conn;
>  
> +  memset(&stgm, 0, sizeof(stgm));
> +

Please fix the bugs (if any) instead of silencing the warnings by
memsetting everything to 0.

-- 
Alexandre Julliard
julli...@winehq.org