August 2012 - Wine-Devel - list.winehq.org

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > In my tests (which replicate the behaviour of a target application) if > > an image of say 10x10 pixels is being copied with a magnification world > > transform then the destination image has right/bottom border completely > > wrong, and my patch fixes this. Besides, bilinear interpolation does > > exactly that already - doesn't round pixel positions up, which contradicts > > your explanation. > > The same rule about pixel centers applies with bilinear interpolation. > That means that at the lower-right corner of a stretched image you end > up with places where the lower-right pixel was blended with a pixel > from outside the image. Just write a test with GdipDrawImageI and scenario described above and you will see the problem. In my case it's even more visible because of indirect magnifaction: image with resolution 100 dpi is being copied to device with 300 dpi. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

> In my tests (which replicate the behaviour of a target application) if > an image of say 10x10 pixels is being copied with a magnification world > transform then the destination image has right/bottom border completely > wrong, and my patch fixes this. Besides, bilinear interpolation does > exactly that already - doesn't round pixel positions up, which contradicts > your explanation. The same rule about pixel centers applies with bilinear interpolation. That means that at the lower-right corner of a stretched image you end up with places where the lower-right pixel was blended with a pixel from outside the image.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I know this looks wrong, but it's there for a reason, and it matches > the behavior of the other interpolations. In my tests, the center of a > bitmap pixel is at an integral value, meaning that the pixel at (0,0) > is a rectangle extending from (-0.5, -0.5) to (0.5, 0.5), and if you > enlarge an image you do get out-of-bounds bits on the lower right. > > I'm pretty sure I also tested GdipDrawImageRect separately and got the > same result. In my tests (which replicate the behaviour of a target application) if an image of say 10x10 pixels is being copied with a magnification world transform then the destination image has right/bottom border completely wrong, and my patch fixes this. Besides, bilinear interpolation does exactly that already - doesn't round pixel positions up, which contradicts your explanation. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: Use outside color from image attributes for an out of bounds pixel.

by Vincent Povirk

> if (src_pointf.X >= srcx && src_pointf.X < srcx + srcwidth && src_pointf.Y >= srcy && src_pointf.Y < srcy+srcheight) > *dst_color = resample_bitmap_pixel(&src_area, src_data, bitmap->width, bitmap->height, &src_pointf, imageAttributes, interpolation); > else > - *dst_color = 0; > + *dst_color = imageAttributes->outside_color; It's like this for a reason. This isn't out of the bounds of the source image, which is when imageAttributes would apply. This is out of the bounds of the parallelogram we're drawing, and we should be leaving that pixel alone.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

I know this looks wrong, but it's there for a reason, and it matches the behavior of the other interpolations. In my tests, the center of a bitmap pixel is at an integral value, meaning that the pixel at (0,0) is a rectangle extending from (-0.5, -0.5) to (0.5, 0.5), and if you enlarge an image you do get out-of-bounds bits on the lower right. I'm pretty sure I also tested GdipDrawImageRect separately and got the same result.

Aug. 28, 2012

re: xmllite: Store DTD processing mode in reader

by Dan Kegel

Alexandre Julliard wrote: > Explicit ok() calls are better than hiding them inside a macro. Uh-oh. Want me to get rid of this macro +#define CHECK_RET_ERRNO(ret, ex) \ + do { \ + ok(ret == ex, "ret is %d, expected %d\n", ret, ex); \ + ok(errno == ex, "errno is %d, expected %d\n", errno, ex); \ + } while (0) in http://source.winehq.org/patches/data/89349 ?

Aug. 27, 2012

Re: [PATCH 1/2] msvcrt: Detect UTF-8 mode

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -1286,6 +1288,17 @@ static int msvcrt_get_flags(const MSVCRT_wchar_t* mode, int *open_flags, int* st > case '+': > case ' ': > break; > + case ',': > + if (!memcmp(mode, encoding_utf8, sizeof(encoding_utf8)) ) > + { > + *open_flags |= MSVCRT__O_U8TEXT; > + *open_flags &= ~(MSVCRT__O_TEXT | MSVCRT__O_BINARY | MSVCRT__O_WTEXT | MSVCRT__O_U16TEXT); > + mode += (sizeof(encoding_utf8)/sizeof(MSVCRT_wchar_t)); > + } > + else > + FIXME("mode %s not supported\n", debugstr_w(mode -1)); Your string parsing needs more work. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2012

Re: xmllite: Store DTD processing mode in reader

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -350,34 +353,47 @@ static void test_reader_create(void) > HRESULT hr; > IXmlReader *reader; > IUnknown *input; > + DtdProcessing dtd; > > /* crashes native */ > if (0) > { > pCreateXmlReader(&IID_IXmlReader, NULL, NULL); > - pCreateXmlReader(NULL, (LPVOID*)&reader, NULL); > + pCreateXmlReader(NULL, (void**)&reader, NULL); > } > > - hr = pCreateXmlReader(&IID_IXmlReader, (LPVOID*)&reader, NULL); > - ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + hr = pCreateXmlReader(&IID_IXmlReader, (void**)&reader, NULL); > + EXPECT_HR(hr, S_OK); > > test_read_state(reader, XmlReadState_Closed, -1, FALSE); > > + dtd = 2; > + hr = IXmlReader_GetProperty(reader, XmlReaderProperty_DtdProcessing, (LONG_PTR*)&dtd); > + EXPECT_HR(hr, S_OK); > + ok(dtd == DtdProcessing_Prohibit, "got %d\n", dtd); > + > + dtd = 2; > + hr = IXmlReader_SetProperty(reader, XmlReaderProperty_DtdProcessing, dtd); > + EXPECT_HR(hr, E_INVALIDARG); > + > + hr = IXmlReader_SetProperty(reader, XmlReaderProperty_DtdProcessing, -1); > + EXPECT_HR(hr, E_INVALIDARG); > + > /* Null input pointer, releases previous input */ > hr = IXmlReader_SetInput(reader, NULL); > - ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + EXPECT_HR(hr, S_OK); Explicit ok() calls are better than hiding them inside a macro. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> If there are only cosmetic objections, I'd like to see this patch accepted, > and work of further improvements after that. I asked Alexandre to wait until I had more time to understand/test this patch. It seems you've introduced a problem with scaling (see attached test program and screenshot). I think that MeasureString is working correctly in this case, and DrawString/MeasureCharacterRanges are wrong. This sort of problem would be less likely if the logic were in gdip_format_string.

Aug. 27, 2012

Re: Unused msvcp100 functions?

by Piotr Caban

On 08/27/12 02:02, Francois Gouget wrote: > There are a lot of msvcp100 functions that look like they are unused: > > * In string.c all of the MSVCP__String_base_*(), > MSVCP_basic_string_*(), MSVCP_basic_string_wchar_*() and > MSVCP_char_traits_*() functions, > basic_string_w?char_replace_helper(). > > * In locale.c _Locinfo__Locinfo_ctor_bstr(), > codecvt_{short,wchar}__Id_func(), collate_{char,short}__Getcat(), > various ctype_*() functions, etc. > > * In ios.c, the basic_istream_*() and basic_ostream_*() functions, > ios_base_Index_func() and ios_base_Sync_func(). > > * In math.c a lot of std_Ctraits_{double,float,long}_*() functions. > > Is it just that the spec file needs to catch up or that they will be > used soon? All of this functions are probably not going to be used. I was not removing them to make syncing between msvcp90 and msvcp100 easier. Currently files in these dlls are almost identical. Feel free to remove unused functions.

Aug. 27, 2012