On Fri, Aug 14, 2009 at 3:10 PM, Keith
Muir wrote:
> What disturbs me about the conformance tests is that yes there are 0%
> failures but when you check you discover its 0% failures on virtual
> machines. Failures on real hardware under XP can reach as high as 6% with
> peaks greater than that. Win
Thanks, I will do it later
Regards
Sunny
-Original Message-
From: Henri Verbeet [mailto:hverb...@gmail.com]
Sent: Friday, August 14, 2009 7:26 PM
To: Sun, Sunny
Cc: wine-devel@winehq.org
Subject: Re: about video memory detection in wine
Could you please subscribe to wine-devel
(http://ww
Hi
We have implemented GL_TOTAL_PHYSICAL_MEMORY for about 8 months, so you will
not get the GL_INVALID_ENUM error. I think it will be documented later.
I have tested with your patch with 3 ATI asics, all of them can get the correct
amount of video memory (1GB, 256MB, 128MB).
For the reason tha
Hi
I think it is difficult to maintain a large list of all ASICs, for you have to
change the list from time to time when a new ASIC is released. Actually we have
provided the functionality for getting total video memory, you can use the
following code to get the total video memory with ATI card
Hi Stefan,
>> + if((needs_quote = NULL != strstrW(wszApplicationName,wSpace)))
>> + len +=2;
>>
> i don't understand what you mean here with "complicated", please explain it.
Questions of style are always in the eye of the beholder, aren't they? ;-)
I'd say breaking the statement into
Am Friday 14 August 2009 18:05:23 schrieb Juan Lang:
>
> Finally, this isn't about whitespace but style:
> +if((needs_quote = NULL != strstrW(wszApplicationName,wSpace)))
> +len +=2;
>
> The expression in the if is unnecessary complicated. You could use
> consistent spacing here too.
H
Am Friday 14 August 2009 18:52:36 schrieb Henri Verbeet:
> I'm only seeing half of the discussion here (the other half is
> probably still in moderation...), but that doesn't sound like a good
> idea. Is there any reason the extension can't be fixed to include
> this, or alternatively a second exte
What disturbs me about the conformance tests is that yes there are 0%
failures but when you check you discover its 0% failures on virtual
machines. Failures on real hardware under XP can reach as high as 6%
with peaks greater than that. Windows is tolerant of all types of
hardware wine still is
On Fri, Aug 14, 2009 at 9:41 PM, Stephen Eilert wrote:
>
>
>
> On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha wrote:
>>
>> This seems like the wrong way to go. I'm wondering if there is another way
>> to detect VRAM? There should be a way to determine VRAM from Xorg? Why
>> should OpenGL or Direct
On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha wrote:
> This seems like the wrong way to go. I'm wondering if there is another way
> to detect VRAM? There should be a way to determine VRAM from Xorg? Why
> should OpenGL or DirectDraw be the method that Wine uses to determine video
> RAM? Why shou
This seems like the wrong way to go. I'm wondering if there is another way
to detect VRAM? There should be a way to determine VRAM from Xorg? Why
should OpenGL or DirectDraw be the method that Wine uses to determine video
RAM? Why should Wine have a fixed value based on a list? Maybe I'm being
stup
On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösinger wrote:
> Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny:
>> +if(gl_info->vidmem < 64 * 1024 * 1024)
>> +gl_info->vidmem = 64 * 1024 * 1024;
> I guess the idea is that no ATI card that was ever supported on fglrx has less
>
2009/8/14 Stefan Dösinger :
> Using the undocumented value and the check for older drivers which don't
> support it is a bit hacky, but its a well-isolated hack and avoids a lot of
> problems, so it should be ok.
>
I'm only seeing half of the discussion here (the other half is
probably still in mod
Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny:
> + if(gl_info->vidmem < 64 * 1024 * 1024)
> + gl_info->vidmem = 64 * 1024 * 1024;
I guess the idea is that no ATI card that was ever supported on fglrx has less
than 64 mb of memory? My old radeon 9000, which isn't supported
Hi again Stefan, I just took a little closer look, and you have more
whitespace issues in the patch:
- LPCWSTR p = space + 1;
+ LPCWSTR p = wszApplicationName + idx + 1;
Why two spaces after the =?
+strcatW(wcmd, wQuote);
+} else
strcpyW(wcmd,
Hi Stefan, I know this is nitpicking, but:
- memcpy(buffer, sei_tmp.lpFile, idx * sizeof(WCHAR));
+lstrcpynW(buffer, wszApplicationName, sizeof(buffer)/sizeof(WCHAR));
+ while((space=strchrW(buffer, ' ')))
You're mixing tabs and spaces here.
--Juan
Nikolay Sivov wrote:
Andrew Eikum wrote:
---
dlls/gdiplus/graphics.c | 19 -
dlls/gdiplus/tests/graphics.c | 162
+
2 files changed, 177 insertions(+), 4 deletions(-)
Could you do it in opposite direction - implement "I" version on top of
Am Friday 14 August 2009 15:44:42 schrieb Henri Verbeet:
> 2009/8/14 chris ahrendt :
> > [../wine-git/dlls/wined3d/arb_program_shader.c:820]: (all) Buffer overrun
> > [../wine-git/dlls/wined3d/arb_program_shader.c:821]: (all) Buffer overrun
> > [../wine-git/dlls/wined3d/arb_program_shader.c:966]: (
On 2009.08.14 17:28, Paul Vriens wrote:
> Hi,
>
> Again, passing pedantic in the URL gets a different behavior. In
> pedantic mode there will always be a direct comparison with English(US)
> when there are warnings.
>
> Changelog
> Add pedantic possibilities to the resource page
>
You forgot t
2009/8/14 chris ahrendt :
> [../wine-git/dlls/wined3d/arb_program_shader.c:820]: (all) Buffer overrun
> [../wine-git/dlls/wined3d/arb_program_shader.c:821]: (all) Buffer overrun
> [../wine-git/dlls/wined3d/arb_program_shader.c:966]: (all) Buffer overrun
> [../wine-git/dlls/wined3d/arb_program_shade
[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1
[../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a
deallocated pointer: stream2
[../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3
[../wine-git/dlls/msvcrt/tests/file.c:973]: (error)
> dbghelp: Fixed arena allocation in pool_alloc.
Well, 'fixed' might be a wrong word, but this patch makes it more intuitive.
Jacek
Vincent Povirk writes:
> On Fri, Aug 14, 2009 at 4:55 AM, Alexandre Julliard
> wrote:
>> Much better this way, thanks. You should probably rename the test file
>> to converter.c or something like that though.
>
> That will be a problem when I want to use the test IWICBitmapSource
> with an encod
On Fri, Aug 14, 2009 at 4:55 AM, Alexandre Julliard wrote:
> Much better this way, thanks. You should probably rename the test file
> to converter.c or something like that though.
That will be a problem when I want to use the test IWICBitmapSource
with an encoder. Or should I just duplicate the co
On Fri, Aug 14, 2009 at 12:52:48PM +0200, Michael Stefaniuc wrote:
> Alexandre Julliard wrote:
> > Marcus Meissner writes:
> >
> >> On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote:
> >>> Austin English writes:
> >>>
> On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
> >>
Could you please subscribe to wine-devel
(http://www.winehq.org/mailman/listinfo/wine-devel) so your mail
doesn't have to go through moderation? It's possible to disable mail
delivery if you don't want to receive all the mail.
Hi,
Can you give the attached patches a try? Do they detect the correct amount of
video memory?
Thanks,
Stefan
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny:
> Hi
>
> I think it is difficult to maintain a large list of all ASICs, for you have
> to change the list from time to time when a
Alexandre Julliard wrote:
> Marcus Meissner writes:
>
>> On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote:
>>> Austin English writes:
>>>
On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
>> All the more reason to use the existing libmpg123 instead of trying to
>>
Marcus Meissner writes:
> On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote:
>> Austin English writes:
>>
>> > On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
>> >>> All the more reason to use the existing libmpg123 instead of trying to
>> >>> maintain our own version, IMO.
>
Am Friday 14 August 2009 12:13:01 schrieb Henri Verbeet:
> 2009/8/14 Stefan Dösinger :
> > Am Friday 14 August 2009 09:23:25 schrieb Henri Verbeet:
> >> For most cards this should make more sense than RTL_READDRAW, even if
> >> e.g. surface_upload_data() has some room for improvement.
> >
> > I don
Ken Thomases writes:
> Hi Alexandre,
>
> It seems this would fail to ignore a fat Mach-O library that doesn't
> include the right 32/64 class. For example, a fat i386/ppc library
> when running 64-bit.
>
> A fat library starts with the struct fat_header defined in /usr/
> include/mach-o/fat.h, f
Alistair Leslie-Hughes writes:
> +static int wineXmlMatchCallback (char const * filename)
> +{
> +static const WCHAR sColon[] = {':',0};
> +BSTR sFilename = bstr_from_xmlChar( (xmlChar*)filename);
> +int nRet = 0;
> +
> +TRACE("%s\n", debugstr_w(sFilename));
> +
> +/*
> +
Hi Alexandre,
It seems this would fail to ignore a fat Mach-O library that doesn't
include the right 32/64 class. For example, a fat i386/ppc library
when running 64-bit.
A fat library starts with the struct fat_header defined in /usr/
include/mach-o/fat.h, followed by a number of struct
2009/8/14 Stefan Dösinger :
> Am Friday 14 August 2009 09:23:25 schrieb Henri Verbeet:
>> For most cards this should make more sense than RTL_READDRAW, even if e.g.
>> surface_upload_data() has some room for improvement.
> I don't think this is a good idea until the READDRAW code has the ability to
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny:
> #define GL_TOTAL_PHYSICAL_MEMORY_ATI0x87FE
> const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS);
> if(strstr(glExtensions, "GL_ATI_meminfo"))
That sounds very helpful! Is this supported on all drivers that support
GL_ATI_m
"Vincent Povirk" writes:
> +START_TEST(testsrc)
> +{
> +CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
> +
> +test_conversion(&testdata_32bppBGRA, &testdata_32bppBGR, "BGRA -> BGR",
> 0);
> +test_conversion(&testdata_32bppBGR, &testdata_32bppBGRA, "BGR -> BGRA",
> 0);
> +test_c
Am Friday 14 August 2009 09:23:25 schrieb Henri Verbeet:
> For most cards this should make more sense than RTL_READDRAW, even if e.g.
> surface_upload_data() has some room for improvement.
I don't think this is a good idea until the READDRAW code has the ability to
only upload a part of the surfac
Michael Karcher writes:
> This patch adds todo_wine statements to the test case, as this patch
> enables the test case to run on wine.
It would be cleaner to store the state in process.c rather than adding
yet another internal function to retrieve it.
--
Alexandre Julliard
julli...@winehq.org
38 matches
Mail list logo
