On 7/11/2012 18:03, Oleg Jakobsen wrote:
Looked at how you decode msi-stream names, and spotted a minor error
whith the decoding.
regards
Oleg
Why do you think it's an error? Looks like in this case it decodes one
input WCHAR to two output WCHARs in a single pass.
Vincent Povirk wrote:
> >> The test in 2/5 was for gdiplus, not WIC.
> >
> > My understanding is that gdiplus just reports what WIC returns in that
> > regard,
> > and gdiplus doesn't generate fake palettes for real images (read: loaded
> > from
> > a stream or a file).
>
> WIC did report a gr
André Hentschel writes:
> @@ -39,10 +44,19 @@ static void init(void)
> pmemcpy_s = (void*)GetProcAddress(hmod, "memcpy_s");
> pI10_OUTPUT = (void*)GetProcAddress(hmod, "$I10_OUTPUT");
> pstrerror_s = (void *)GetProcAddress(hmod, "strerror_s");
> +pbsearch_s = (void *)GetProcAdd
>> The test in 2/5 was for gdiplus, not WIC.
>
> My understanding is that gdiplus just reports what WIC returns in that regard,
> and gdiplus doesn't generate fake palettes for real images (read: loaded from
> a stream or a file).
WIC did report a grayscale palette, implicitly in the pixel format.
Vincent Povirk wrote:
> Shouldn't your second LockBits in this loop always use
> PixelFormat24bppRGB and ImageLockModeRead? As it is, if the
> LockBits/UnlockBits is writing but not reading, you won't be able to
> tell.
Probably that would simplify the test a bit, but I don't see a problem
with
Vincent Povirk wrote:
> >> Are you sure about this? My understanding is that the result of
> >> CopyPalette is unspecified when your pixel format is not an indexed
> >> color format (in this case, a grayscale format).
> >
> > It seems that WIC always creates a predefined palette if an image doesn
Henri Verbeet writes:
> @@ -276,18 +274,15 @@ void X11DRV_XRandR_Init(void)
>
> /* see if Xrandr is available */
> wine_tsx11_lock();
> -ok = pXRRQueryExtension(gdi_display, &xrandr_event, &xrandr_error);
> -if (ok)
> -{
> -X11DRV_expect_error(gdi_display, XRandREr
>> Are you sure about this? My understanding is that the result of
>> CopyPalette is unspecified when your pixel format is not an indexed
>> color format (in this case, a grayscale format).
>
> It seems that WIC always creates a predefined palette if an image doesn't
> have one, see the test sent i
Vincent Povirk wrote:
> Are you sure about this? My understanding is that the result of
> CopyPalette is unspecified when your pixel format is not an indexed
> color format (in this case, a grayscale format).
It seems that WIC always creates a predefined palette if an image doesn't
have one, see
Shouldn't your second LockBits in this loop always use
PixelFormat24bppRGB and ImageLockModeRead? As it is, if the
LockBits/UnlockBits is writing but not reading, you won't be able to
tell.
Also, you might want to try flags == 0 in some pixel format other than
24bppRGB. As I understand it, all mod
Are you sure about this? My understanding is that the result of
CopyPalette is unspecified when your pixel format is not an indexed
color format (in this case, a grayscale format).
So, while it's not really a problem to do that (unless a program
relies on the exact behavior of this decoder, which
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
http://testbot.winehq.org/JobDetails.pl?Key=19930
Your paranoid android
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
http://testbot.winehq.org/JobDetails.pl?Key=19931
Your paranoid android
13 matches
Mail list logo
