Re: Updating WineWiki Theme?
On Thu, 14 Mar 2013, Kyle Auble wrote: [...] > I did want to ask for input on a few things: [...] Sorry, I don't have anything useful to contribute on these. However since this is about the Wiki theming I'll mention a problem I ran into last week-end: tables. There are two problems with them: * A default table is totally ugly: it has no border and no cell padding so it does not look like a table at all, just text appearing at random on the page. Here is an example: http://wiki.winehq.org/FrancoisGouget * During the preview the tables look nothing like after the preview. In fact they look good enough during the preview, it's only on the final page that they get ugly. This makes the preview totally useless as far as tables are concerned :-( In the page I was working on I worked around this by specifying CSS styles for every single cell. The resulting wiki source code is pretty ugly but at least the result looks like tables. http://wiki.winehq.org/WineTestBotVMs#hw_tables Oh, and the Wiki seems to have trouble sending emails(*) so saving changes is super slow. But that's probably not something you can do anything about. (*) I get: Status of sending notification mails: [en] fracting: Connection to mailserver 'mail.lattica.com' failed: (101, 'Network is unreachable') -- Francois Gouget http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
Re: WineD3D performance
Am 14.03.2013 um 20:07 schrieb Graham Knap : > I would like to try to help with improving the performance of > StarCraft II on Wine. I'm working with a friend. Over the past couple > of weeks, we have tried to read whatever documentation we could find. > We have tried a couple of different approaches to profiling, without > much success. That's great :-) Note however that improving performance is not a weekend's job. It needs a lot of careful profiling, testing and bugfixing. > Can anyone offer some hints on how to find the most significant causes > of the performance difference? Any tips for effective profiling or > tracing? Depending on your settings, you may be CPU or GPU limited. A rule of thumb way to find out is to change the game's resolution - if increasing the resolution causes a big framerate drop, you're probably GPU limited. If the framerate stays the same, you're CPU limited. In the GPU limited case, improving the situation requires a tedious work to find shaders that execute slower, finding out why they are slower and then fixing things. It also needs double-checking with other games and GPUs to make sure that you're not optimizing one game at the cost of another. In the CPU limited case, I believe the main reason is that native is able to move a lot of the CPU-side work to a different thread, thus utilizing two CPU cores. You can test that theory by forcing Windows to run with one CPU only (use msconfig for that) and comparing performance again. Aside of the worker thread, there may be some parts of the wined3d code that can be optimized. Like the GPU side work, this requires a lot of careful testing, fixing and double-checking. Stefan
Re: Aric Stewart : usp10: Update diacritical script handling for non OpenType Itemization.
Hello, On Fri, Mar 15, 2013 at 12:52 AM, Aric Stewart wrote: > I am just getting back from a vacation so I will review this and your other > patch early next week when I am fully back. > > Thanks for doing work here! Thanks for replying, wasn't sure you saw my posts. And of course thanks for your work too. -- Ph.
Re: Aric Stewart : usp10: Update diacritical script handling for non OpenType Itemization.
On 3/7/13 4:57 AM, Phil Krylov wrote:
> Hello Aric,
>
> On Tue, Feb 5, 2013 at 11:25 PM, Alexandre Julliard
> wrote:
>> Module: wine
>> Branch: master
>> Commit: ef4b7c5948e43d4ceeed98ba4ddbf6c59d36
>> URL:
>> http://source.winehq.org/git/wine.git/?a=commit;h=ef4b7c5948e43d4ceeed98ba4ddbf6c59d36
>>
>> Author: Aric Stewart
>> Date: Tue Feb 5 08:57:44 2013 -0600
>>
>> usp10: Update diacritical script handling for non OpenType Itemization.
>
> (snip)
>
>> +for (j = i-1; j >= 0 && scripts[j] == first_script &&
>> pwcInChars[j] != Numeric_space; j--)
>> +{
>> +WORD original = scripts[j];
>> +if (original == Script_Ideograph || original ==
>> Script_Kana || original == Script_Yi || original == Script_CJK_Han ||
>> original == Script_Bopomofo)
>> +{
>> +asian = TRUE;
>> +break;
>> +}
>> +if (original != Script_MathAlpha &&
>> scriptInformation[scripts[j]].props.fComplex)
>> +break;
>> +scripts[j] = scripts[i];
>> +if (original == Script_Punctuation2)
>> +break;
>> +}
>> +if (scriptInformation[scripts[j]].props.fComplex ||
>> asian)
>> +scripts[i] = scripts[j];
>
> I am not sure about the logic of this, so I can't commit a good patch,
> but in the last statement you definitely access scripts[-1] when j
> reaches the value of 0. Which may cause a crash here or (in my case)
> later.
>
> -- Ph.
>
>
Hi there,
I am just getting back from a vacation so I will review this and your other
patch early next week when I am fully back.
Thanks for doing work here!
-aric
Updating WineWiki Theme?
Hi everybody, Although my hiatus was longer than expected, I've been making progress with updating the wiki code over the past few days (spring break is a very good thing). My workflow is a bit non-linear so I want to sort my changes into patches first, but fingers-crossed, I'll be pushing them to my Bitbucket account by the weekend. I did want to ask for input on a few things: 1. Should we just keep Moinmoin's search, replace it with the custom Google search, or offer both? 2. How about the icon? I can get the standard WineHQ one to display fine, but I'm not sure about which approach to take. Essentially, do what's simplest for us, or should I make it play well with other themes too? 3. Finally, the credits are currently just text links. In the future though, if Dimi wanted to, we could have a "sponsored by Lattica" banner like the Codeweavers ones on the other pages. After I get the theme together & test it some more on different browsers, I can look into migrating the data to the newest Moinmoin version. -Kyle
WineD3D performance
Hi everyone I would like to try to help with improving the performance of StarCraft II on Wine. I'm working with a friend. Over the past couple of weeks, we have tried to read whatever documentation we could find. We have tried a couple of different approaches to profiling, without much success. My friend got WineD3D running on Windows. We built Wine from current source code, tested this on two different configurations, and got similar results. - my Core 2 E8500 + GeForce 9600GT + Windows XP x86 - his i5-2500 + GeForce 660 + Windows 7 x64 It looks like WineD3D is the cause of most of the performance difference. Windows with its own D3D gave us at least twice the frame rate of Windows + WineD3D. There is some difference between the numbers for Windows + WineD3D and Linux + Wine, but it's much smaller, i.e. something like 25%. Can anyone offer some hints on how to find the most significant causes of the performance difference? Any tips for effective profiling or tracing? Thanks. -- graham
Re: d3dx9 [patch 1/2]: Implement D3DXSHEvalSphericalLight
2013/3/14 Nozomi Kodama : > No news about these patches? > > > Nozomi? > > Hmm, I was under the impression that these patches were already picked up in git, but I see I was mistaken. Anyway they look okay to me, except for a bit in the tests from the first patch that I noticed just now by reading the patches again: +else if (j >= order * order) +expected = test[l].red_received[j]; That somewhat defies the test, since you are then comparing a value with itself in the ok(). You can just use the original value (i.e. "1.01f + j" for the red component) instead. Same issue with green and blue of course. Cheers, Matteo. > > De : Nozomi Kodama > À : "wine-devel@winehq.org" > Envoyé le : Lundi 11 mars 2013 17h11 > Objet : RE: d3dx9 [patch 1/2]: Implement D3DXSHEvalSphericalLight > > Hello > > Any problem with the patch > http://source.winehq.org/patches/data/94777 > > and > http://source.winehq.org/patches/data/94776 ? > > Nozomi. > >
Re: winegcc: Add support for -Ttext-segment linker flag to set image base of a dll. (try 2)
Tijl Coosemans writes: > Loading a library at a specific address not only depends on the > compile-time linker, but also on the run-time loader, so it's > probably best to implement -image-base only on PLATFORM_* where > the loader supports it. Since a target platform would then have > to choose to use PLATFORM_ELF explicitly I think it's reasonable > for PLATFORM_ELF to have a dependency on binutils>=2.20 (or > compatible) rather than a run-time test for -Ttext-segment > support. The gold linker doesn't support it even in recent binutils versions, and some systems use that by default. -- Alexandre Julliard julli...@winehq.org
