Vincent Povirk wrote:
> > 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 at
>> I just did, and the behavior, though it looks wrong, is the same
>> between builtin and native - the image is shifted by 1/2 pixel so that
>> it's cut off at the upper-left and we have extra transparent space at
>> the lower-right.
>
> With native gdiplus scenario described earlier works just fi
Vincent Povirk wrote:
> > 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.
>
> I just did, and the
> 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.
I just did, and the behavior, though it looks wrong, is
Vincent Povirk 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, bil
> 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
> exact
Vincent Povirk 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),
> 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,
> interp
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
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"
Detlef Riekenberg 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_
Nikolay Sivov 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);
> -
> 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).
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_hel
14 matches
Mail list logo
