Vincent Povirk wrote:
> The right solution is to remove the gdibrush and logbrush fields from
> GpBrush, and generate the HBRUSH as needed in brush_fill_path. Note
> that brush_fill_path will only be called for solid and hatch brushes
> (those for which brush_can_fill_path returns true), so we do
On Feb 28, 2012, at 10:58 PM, Chris Robinson wrote:
> On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote:
>> + * This is basically the same as the pa_threaded_mainloop implementation,
>> + * but that cannot be used because it uses pthread_create directly
>> + *
>> + * pa_threaded_ma
On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote:
> + * This is basically the same as the pa_threaded_mainloop implementation,
> + * but that cannot be used because it uses pthread_create directly
> + *
> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock
> + * pa_threaded_
2012/2/28 Luca Bennati :
> I tried converting README.it to UTF8, instead of the current Extended ASCII,
> which works really bad on my system.
> However, it does not seems like Git caught this change: could this be done
> manually?
I applied the patch manually and it seems the conversion went fine
OK, I came up with something.
We can lock up the wiki registration and the Admin will have to approve
each and every translator manually (TranslateWiki works that way when you
want to contribute to MediaWiki).
That way the user will have to provide his/her real name upon registration.
There's al
Hi,
I rechecked the translation with old zh_TW.po file. I used Kompare
and picked the better one for each entry. I hope that the new patch
file is okay and acceptable.
I'll post the new patch again later.
BTW, the Chinese name (used in Taiwan) of Free Software Foundation is
"自由軟體基金會", that's c
Hey Dmitry,
Op 28-02-12 18:42, Dmitry Timoshkov schreef:
> Maarten Lankhorst wrote:
>
>> >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001
>> From: Maarten Lankhorst
>> Date: Thu, 28 Apr 2011 09:45:18 +0200
>> Subject: [PATCH 10/10] winepulse: Add pulse driver, v8
> You for
Maarten Lankhorst wrote:
> >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001
> From: Maarten Lankhorst
> Date: Thu, 28 Apr 2011 09:45:18 +0200
> Subject: [PATCH 10/10] winepulse: Add pulse driver, v8
You forgot to fix the date, 1 Apr would be more appropriate I'd guess.
-
Hi Andrew,
one small contribution:
> Winmm's timer functions use poll() with a timeout value, subtracting
> the time elapsed curing the callback. This works quite well in dsound.
>
> The Win32 API also provides the SetTimer API. But that depends on a
> message queue, which is a hassle I don't kno
On Tue, Feb 28, 2012 at 08:24:37AM -0600, Andrew Eikum wrote:
> I'm investigating native TimerQueue's operation now. If it turns out
> that TimerQueue isn't sufficient, we'll probably just switch over to
> using poll() like winmm's timer stuff does.
>
And, not too surprisingly, TimerQueue isn't s
Am Dienstag, 28. Februar 2012, 14:51:06 schrieb Henri Verbeet:
> Yes, but that's the other way around. If anything, that pdf suggests
> that buffers are dynamic by default in ddraw.
Making buffers dynamic by default in ddraw will disable rhw vertex and color
conversion for ddraw apps.
We could cr
Am Dienstag, 28. Februar 2012, 14:50:28 schrieb Henri Verbeet:
> Ok, but we could just be more clever about doing uploads and only
> upload what's actually referenced by draws. We already have most of
> the code for tracking uploaded ranges. Similarly, are we really sure
> that maintaining a sysmem
On Mon, Feb 27, 2012 at 11:41:56PM +0100, Maarten Lankhorst wrote:
> > W.r.t. to 1.4.0, I believe the following path should be taken:
> > - Write CreateTimerQueue tests to verify whether native behaves like:
> > a) sleep(Xms) /* what Wine does now */ or
> > b) sleep(Xms - elapsed) /*
On 28 February 2012 14:17, Stefan Dösinger wrote:
> Am Dienstag, 28. Februar 2012, 13:05:16 schrieb Henri Verbeet:
>> I don't see why WRITEONLY should imply DYNAMIC.
> For one, the documents from nvidia tell you to set D3DVBCAPS_WRITEONLY when
> you want to stream data[1]. Microsoft doesn't really
On 28 February 2012 13:46, Stefan Dösinger wrote:
> buffer_direct_upload is working correctly and the gl buffer is mapped with
> GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT, depending on the
> lock flags the buffer used. The performance hit comes from the memcpy, not the
> buffer map
Am Dienstag, 28. Februar 2012, 13:05:16 schrieb Henri Verbeet:
> I don't see why WRITEONLY should imply DYNAMIC.
For one, the documents from nvidia tell you to set D3DVBCAPS_WRITEONLY when
you want to stream data[1]. Microsoft doesn't really document how dynamic
buffers work in d3d7.
The other c
Hi,
I have had quite a long discussion with the TranslateWiki people. They
are great and while what we need would require a bit of PHP development
they expressed that they would be happy to do the work.
The main sticking block is that our requirement for Real Names and
e-mail for all contri
Am Dienstag, 28. Februar 2012, 13:05:36 schrieb Henri Verbeet:
> I don't find this all that convincing either. My impression is that
> the reason we have these kinds of problems is mostly that the buffer
> conversion code is broken. I don't think there are legitimate cases
> where not creating a VB
On 28 February 2012 12:19, Stefan Dösinger wrote:
> This is for bug 30019.
>
> They are a lot slower than using no VBO at all in at least some, if not all
> games. The reason for the slowdown is the memcpy call, not the buffer
> map.
I don't find this all that convincing either. My impression is t
On 28 February 2012 12:19, Stefan Dösinger wrote:
> This is for bug 30019.
>
> Out ddraw.dll forwards DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to
> wined3d, but wined3d ignores those flags because we never set
> WINED3DUSAGE_DYNAMIC. D3d7 docs refer to D3DVBCAPS_WRITEONLY as the flag
> to set
On Mon, 27 Feb 2012, David wrote:
> Hello.
>
> There is attached a small cs.po update. Gzipped. Generated using
> winepo. More is coming. I am planning to update it all. Last will be
> translation of certificates/encryption strings.
Thanks for the translation update. Unfortunately the tool you
On Mon, 27 Feb 2012, Hin-Tak Leung wrote:
[...]
> that aside, I think you are quite wrong in trying to "improve user
> experience". That's a matter of opinion - and unfortunately, I have
> already pointed out, some of the changes are just opinions, and
> therefore subject to churns - i.e. some w
On Mon, 27 Feb 2012, Hin-Tak Leung wrote:
[...]
> > Do not do that. That would be copyright infrigement. That's
> > not what we
> > want. This would get your contributions removed from Wine.
>
> claiming copyright on short phrases like 'loading dlls failed' (in
> whatever language) seems very fa
On Mon, Feb 27, 2012 at 11:23, Robert van Herk
wrote:
>> So what actually prevents you from properly implementing this? Especially
>> that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY
>>
>> Vitaliy.
>
> I wrote a new version that maps
> 'D' -> MSVCRT__O_TEMPORARY, and
> 'T
24 matches
Mail list logo
