[PATCH 1/5] winmm: Improve MCI's Sysinfo command.
Hi, Eric Pouech wrote: did you test the 16 = 32 bit conversion for the MCI_ALL_DEVICE ? Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID that pass on both win9x and later (also in patch #5). I wrote a few more MCI tests privately. Generally, I added (UINT16) casts in Wine when I saw test failures on Win9x platforms, then kept doing so (i.e. I'm not sure I've tested SYSINFO with a deviceID on Win9x in particular or whether I simply use that pattern everywhere now after having been burnt once). There are a few patches already in git that fix a few MCI_ALL_DEVICE_ID here and there, but as you wrote yourself in the TODO header long ago, support for it is incomplete. Making close all, play all etc. work is on my private TODO list, but I never started working on this particular item. actually, I'd say it belongs to the 16=32 mci message mapper, not in generic 32bit code Do you mean dlls/mmsystem.dll16? I never looked at it but I don't think that's the correct place, see below. Do you mean the A/W (un)mapping? That's distinct, because it deals with string conversions only, as the name suggests, and it does not mogrify dwParam1. Current test results suggest that MCI_ALL_DEVICE_ID is not only a 16/32 issue -- at least when I equate 16 with MS-Windows 3.x -- Have a look at the mciGetDeviceID(all) test case, which returns a 16bit on Win9x, not . Therefore I believe Wine must be prepared for receiving as ALL_ID from old Win9X apps or drivers -- possibly regardless of them using the A or W function entry points. Of course, a single (or few) central place(s) to convert wDeviceID=(MCIDEVICEID)(WORD)wDeviceID or wDeviceID= wDeviceID==0x ? MCI_DEVICE_ALL_ID : wDeviceID is a nice idea. That could be a distinct patch. I'm convinced this handle is truly a 16 bit entity, even after it has been upgraded to a UINT/DWORD type at some time in the past. Still, SYSINFO is a special case, as it receives a device ID not only as function argument but also in its PARMS structure. Regards, Jörg Höhle.
Summer of Code applicant with ambition!
Hello wine-devel, My name is John and I'm a computer science major at the University of Minnesota, Twin Cities campus. I've made quite a bit of use of Wine before (and I have purchased Crossover) and I'm inspired to give something back to the project. I have fairly ambitious goals for myself (maybe too much so) so I wanted to let you guys know who I am and what I'd like to do, then hopefully gain some insight into whether or not what I am considering is reasonable. My experience is roughly as follows: * I am familiar with C. I'm not an expert developer by any stretch but I can certainly get by. I have some knowledge of Git. * I don't have any Windows development experience outside of some exposure to .NET a long time ago. * I have not submitted a patch to the Wine project. I hope to change this in the near future. I've looked at a little bit of the source code. * I have high standards for myself. Whether or not they are high enough to meet Alexandre's expectations... perhaps time will tell. :-) * I'm a really fast learner. Maybe this is my single most redeeming quality. All that being said, my goal for the summer would be to really dig into the D3D stuff, optimizing what is already completed and adding to what is not. I'm a gamer myself, so I have an arsenal of programs with which to test (and a Windows installation to compare to). Do you think this goal is reasonable? If not, I could start somewhere smaller and work my way up. I'm certainly open to suggestions. Thanks! John
winmm: For MCI parsing, use 64bit compatible structures.
Hi, Eric Pouech wrote: this patch is ugly as hell... Please qualify. To me, - data[3] = (DWORD_PTR)dev; + parms.open.lpstrElementName = dev; looks more robust than before: - no magic offsets, - no casts that may silence warnings. The one #ifdef WIN64 is a pure performance optimization on Win32. The other one with the TRACE() is indeed ugly, but I don't feel it's safe to call debugstr_w() on misaligned data in Wine64. Even if it were, printing data[3] as string may be wrong, because it may be data[4] (+5) that holds a pointer, not (3+4). Therefore I decided to renounce to print string contents on 64bit, despite their value in the logs. and it still believe we can do the MCI parser without knowing about MCI structures internals What do you mean? Quite to the contrary, the parser depends on knowing the internals of some commands (like MCI_OPEN) as well as the convention about the return value as 2nd (+3rd) slot after the callback. The parser bridges the gap between the resource definition files winmm_res.rc that are now in git and are known to work well with 32bit and the mixed DWORD/DWORD_PTR MCI_..._PARMS definitions whose correctness has been (partially) validated by tests. What we don't know is whether Win64 introduced a different winmm_res.rc. I'd sure would be pleased if somebody could describe whether there have been changes to the resources to accommodate 64bit pointers in MS-Windows. Everybody, please visit bug #22146 if you can contribute such knowledge. (Part of) my patch is needed even if there were (thanks to lack of magic offsets). Regards, Jörg Höhle
Re: Summer of Code applicant with ambition!
On Tue, Mar 30, 2010 at 4:34 PM, John Koelndorfer jkoelndor...@gmail.com wrote: Hello wine-devel, My name is John and I'm a computer science major at the University of Minnesota, Twin Cities campus. I've made quite a bit of use of Wine before (and I have purchased Crossover) and I'm inspired to give something back to the project. I have fairly ambitious goals for myself (maybe too much so) so I wanted to let you guys know who I am and what I'd like to do, then hopefully gain some insight into whether or not what I am considering is reasonable. My experience is roughly as follows: * I am familiar with C. I'm not an expert developer by any stretch but I can certainly get by. I have some knowledge of Git. * I don't have any Windows development experience outside of some exposure to .NET a long time ago. * I have not submitted a patch to the Wine project. I hope to change this in the near future. I've looked at a little bit of the source code. * I have high standards for myself. Whether or not they are high enough to meet Alexandre's expectations... perhaps time will tell. :-) * I'm a really fast learner. Maybe this is my single most redeeming quality. All that being said, my goal for the summer would be to really dig into the D3D stuff, optimizing what is already completed and adding to what is not. I'm a gamer myself, so I have an arsenal of programs with which to test (and a Windows installation to compare to). Do you think this goal is reasonable? If not, I could start somewhere smaller and work my way up. I'm certainly open to suggestions. Thanks! John First of all welcome to Wine. For a gsoc project I would try to work on a somewhat isolated piece of code, so that your work won't break daily and it is also easier to see what you are doing (and writing a good project description might be easier for an isolated project as well). Regarding the Direct3D code, it is quite complex and I don't think it is well suited for a gsoc project (it has a really steep learning curve). A project like 'optimizing Direct3D' is a bit vague and this would also make it hard to see whether you met your goals or not. Last year I would have said that if this area interests you, work on the D3DX9 helper dlls. Right now we have most of the easy 'bits' (though not all parts have been merged) and mainly lack the difficult part namely the HLSL shader compiler, but it is not suited for a GSOC project. I would think about an area which you like to work on (or perhaps a specific app which you really want to improve). Take into account that GSOC is quite short and realize that getting code into Wine can also take time because you might need multiple iterations of a patch and you have to write a lot of unit tests. So try to pick something which is realistic to improve in such an amount of time. Good luck! Roderick
Re: 10/10 wined3d: use RECT instead of WINED3DRECT in stretch_rect_fbo [try2]
Roderick Colenbrander thunderbir...@gmail.com writes: Hi, While working on some other patches, I spotted a small error in the call to surface_get_rect for the source rectangle. I was passing 'This' (destination) instead of Src. It doesn't work: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c touch visual.ok wine: Unhandled page fault on read access to 0x0050 at address 0x68e87fc9 (thread 0024), starting debugger... Unhandled exception: page fault on read access to 0x0050 in 32-bit code (0x68e87fc9). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68e87fc9 ESP:0032f110 EBP:0032f248 EFLAGS:00010246( R- -- I Z- -P- ) EAX:0001 EBX:68ed8d20 ECX:0280 EDX: ESI: EDI:01e0 Stack dump: 0x0032f110: 00146350 68ed2dbc 0032f228 00110014 0x0032f120: beef0202 7d7fb5c0 7bc4907b 68ed8d20 0x0032f130: 00147240 0072 0032f198 68df9e66 0x0032f140: 00147240 0080 0080 0001 0x0032f150: 0012fc70 0072 0x0032f160: 00147000 686cb060 0001 Backtrace: =0 0x68e87fc9 IWineD3DSurfaceImpl_BltOverride+0x1529(This=is not available, DestRect=is not available, SrcSurface=(nil), SrcRect=(nil), Flags=0x1000400, DDBltFx=0x32fa9c, Filter=WINED3DTEXF_POINT) [/home/julliard/wine/wine/dlls/wined3d/surface.c:284] in wined3d (0x0032f248) 1 0x68e8b1e7 IWineD3DSurfaceImpl_Blt+0xb7(iface=register ESI not in topmost frame, DestRect=(nil), SrcSurface=register EDI not in topmost frame, SrcRect=(nil), Flags=0x1000400, DDBltFx=0x32fa9c, Filter=WINED3DTEXF_POINT) [/home/julliard/wine/wine/dlls/wined3d/surface.c:4271] in wined3d (0x0032f2d8) 2 0x686ae1bb IDirectDrawSurfaceImpl_Blt+0x1ab(iface=0x12b888, DestRect=register ESI not in topmost frame, SrcSurface=(nil), SrcRect=(nil), Flags=register EDI not in topmost frame, DDBltFx=0x32fa9c) [/home/julliard/wine/wine/dlls/ddraw/surface.c:806] in ddraw (0x0032f348) 3 0x686b0717 IDirectDrawSurface3Impl_Blt+0x47(This=0x12b88c, prcDst=(nil), pSrcSurf=(nil), prcSrc=(nil), dwFlags=0x1000400, pFX=0x32fa9c) [/home/julliard/wine/wine/dlls/ddraw/surface_thunks.c:113] in ddraw (0x0032f378) 4 0x68663213 D3D1_TextureMapBlendTest+0x263() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:1302] in ddraw_test (0x0032fb88) 5 0x68669bb5 func_visual+0x1375() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:2979] in ddraw_test (0x0032fd48) 6 0x6866a82e run_test+0x14e(name=is not available) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:543] in ddraw_test (0x0032fd98) 7 0x6866aa02 main+0x132(argc=couldn't compute location, argv=couldn't compute location) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:592] in ddraw_test (0x0032fe58) 8 0x6866ab9c __wine_spec_exe_entry+0x7c(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in ddraw_test (0x0032fea8) 9 0x7b8584c4 start_process+0x54(peb=register ESI not in topmost frame) [/home/julliard/wine/wine/dlls/kernel32/process.c:989] in kernel32 (0x0032fee8) 10 0x7bc71344 call_thread_func+0xc() in ntdll (0x0032fef8) 11 0x7bc71510 call_thread_entry_point+0x70(entry=0x7b858470, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2459] in ntdll (0x0032ffc8) 12 0x7bc4cfca in ntdll (+0x3cfca) (0x0032ffe8) 0x68e87fc9 IWineD3DSurfaceImpl_BltOverride+0x1529 [/home/julliard/wine/wine/dlls/wined3d/surface.c:284] in wined3d: movl 0x50(%edx),%eax 284 rect_out-right = This-currentDesc.Width; -- Alexandre Julliard julli...@winehq.org
Re: winedump: code cleanup
Mikhail Maroukhine mik...@yandex.ru writes: - winedump/search.c::get_type - cleanup variable usage That's not much better. It would be cleaner to stop abusing the passed argument as a local variable. -- Alexandre Julliard julli...@winehq.org
Congratulations!
Hi Matteo, just wanted to congratulate you on getting your DRDXAssembleShader patches accepted. I know it can take a fair amount of persistence to get something substantial committed, and it seems that many lack the patience. Well done! --Juan
Implementation of WIndows Gaming APIs as GSoC project
Hello I'm Mariusz Pluciński, student of Information Technology in Gdańsk University of Technology (Poland). I decided to apply to Google Summer of Code in your project, cause I've been fascinated in Wine for a long time (without Wine, migration to open source OS would not be possible for me). In my opinion, one of the biggest problem for Wine is problems with support games written for MS Windows, so making progress in this area is something which I want to work on. I know C programming language very well, just as programming in Microsoft Windows APIs and Microsoft's COM technology. I also have some experience in working on open source - in Kdenlive project (video editor). I do a polish translation there, but I have also sent several patches to source code. In the past I was also reading some parts of Wine source code, so I know somewhat about how Wine's works and how it's code looks. In Google Summer of Code, I'm interested in implementation of new gaming APIs created by Microsoft for Windows Vista and enlarged in Windows 7. Main part of this is implementation of four COM interfaces: IGameExplorer, IGameExplorer2, IGameStatistics and IGameStatisticsMgr. In the bugzilla there's stub implementation of IGameExplorer interface, which may be good start point for me in development. Main parts of task will probably be creation of database to store games' data and parser of GDF files (Game Definition File). In favorable circumstances, if the APIs implementation is done fast enough, I will start work on simple equivalent of Windows Game Explorer application. It would be nice for Wine's users to control their games from one application, similar way as they do it in MS Windows. Also, application will use Game Statistics interfaces, so it will be good practical test for these interfaces. I hope my idea will get your acceptance. Thanks
[PATCH 1/5] winmm: Improve MCI's Sysinfo command.
Hi, Eric Pouech wrote: did you test the 16 = 32 bit conversion for the MCI_ALL_DEVICE ? It's good you asked. Upon closer inspection, MCI_Sysinfo appears to behave differently. I'd say it's even a bug in MS that setting SYSINFO_PARMS.wDeviceType = MCI_ALL_DEVICE_ID is not recognized! Only sendCommand(MCI_ALL_DEVICE_ID, MCI_SYSINFO ...) appears usable to obtain the functionality of sysinfo all ... :-( I'll supersede the patch ASAP. Grr, that's not going to simplify the parser. Regards, Jögr Höhle
Re: Summer of Code applicant with ambition!
snip quoted text Firstly, thanks to Roderick for the prompt reply. I had a feeling that my ideas were a little much. :-) That being said, I've again gone over the list of possible projects on the Summer of Code page and one that particularly piqued my interest was Direct3D - Conformance / Performance / Interactive tests. This seems like it may be a good fit given my lack of previous experience in the Wine codebase. I haven't written any code for 3D-ish games but I can't imagine that would be a huge setback. Maybe Dan Kegel or someone else who has worked on D3D can comment here? If that is not feasible, I think I would be a strong candidate for the Test Suite project since my scripting-fu is fairly strong. I've been looking through open Wine bugs but I've yet to find something that fits with GSOC and my skill level. If there are any suggestions for specific bugs to look into maybe I could build a project around one. Thanks! John
re: Summer of Code applicant with ambition!
John Koelndorfer wrote: I've again gone over the list of possible projects on the Summer of Code page and one that particularly piqued my interest was Direct3D - Conformance / Performance / Interactive tests. This seems like it may be a good fit given my lack of previous experience in the Wine codebase. I haven't written any code for 3D-ish games but I can't imagine that would be a huge setback. Maybe Dan Kegel or someone else who has worked on D3D can comment here? (Correction: I've never worked on D3D :-) Offhand, if you're not already a 3d person, that might be kind of hard? Although maybe the get dxdiag working task might be easy enough. (The only problem with that is it involves committing someone else's code, which isn't a good focus for a GSOC project.) If that is not feasible, I think I would be a strong candidate for the Test Suite project since my scripting-fu is fairly strong. Sure, you could find and fix tons of problems that way, I bet. - Dan
Re: [PATCH 6/7] Use surface_is_offscreen instead of directly looking at the swapchain.
On 30 March 2010 21:19, Roderick Colenbrander thunderbir...@gmail.com wrote:
@@ -4062,7 +4062,7 @@ static HRESULT
IWineD3DSurfaceImpl_BltOverride(IWineD3DSurfaceImpl *This, const
* Also beware that the front buffer's surface size is screen width x
screen height,
* whereas the real gl drawable size is the size of the window.
*/
- if (dstSwapchain (IWineD3DSurface *)This ==
dstSwapchain-frontBuffer) {
+ if (!surface_is_offscreen((IWineD3DSurface *)This)) {
RECT windowsize;
POINT offset = {0,0};
UINT h;
This looks wrong, the code is checking if the surface is the front
buffer, not if it's onscreen.
Re: Summer of Code applicant with ambition!
(Correction: I've never worked on D3D :-) Fair enough, I just noted that you were listed as a possible mentor for that project so I figured you'd be the person to ask. Sure, you could find and fix tons of problems that way, I bet. Well that's good to hear. If that can help the Wine hackers work faster and it's a low-grade learning curve then we might have a winner. Of course, I am still open to other suggestions if there are any.
Re: Summer of Code applicant with ambition!
On Tue, Mar 30, 2010 at 11:04 PM, John Koelndorfer jkoelndor...@gmail.com wrote: (Correction: I've never worked on D3D :-) Fair enough, I just noted that you were listed as a possible mentor for that project so I figured you'd be the person to ask. Sure, you could find and fix tons of problems that way, I bet. Well that's good to hear. If that can help the Wine hackers work faster and it's a low-grade learning curve then we might have a winner. Of course, I am still open to other suggestions if there are any. One useful project could be to finish the DirectShow/Gstreamer work. You would have to ask Edward Hervey about it. A few days ago he mentioned on IRC that he was planning to check the status of the code again and he had suggestions for future work about a generic dshow/gstreamer wrapper. This area is a challenging area though but I think there is not that much porcelain you can break. Roderick
Re: Congratulations!
2010/3/30 Juan Lang juan.l...@gmail.com: Hi Matteo, just wanted to congratulate you on getting your DRDXAssembleShader patches accepted. I know it can take a fair amount of persistence to get something substantial committed, and it seems that many lack the patience. Well done! --Juan Thank you very much! It required quite some time (mostly because of other things stealing time from Wine hacking) and this is not the end of the story, many more (smaller) patches will be needed to complete the implementation. Anyway I really appreciate this, I think I'm going to print your email and hang it somewhere in my room. :)
Re: Summer of Code applicant with ambition!
I've done a little bit of research on Direct3D. Having seen how easy the tutorial at http://www.directxtutorial.com/ is, I think I'd like to propose the following: a 3D benchmarking program that would allow users and developers to determine what aspects of WineD3D are the slowest so that they can be improved. My high level idea is that a user would be able to set graphics options (similar to a game -- or maybe automatically test many configurations) and a 3D demo would run. It would time D3D function calls so that we can get an idea for which functions need optimization, report FPS at points in time, and whatever else makes sense as I learn more about it. As I mentioned before, I haven't really done anything w/ 3D but in my endeavors as a student I've taken up through calculus 4 (including linear algebra) so I think that will give me a leg up here. I plan to do some research on D3D before SOC begins. Does this sound like it would be useful to work on? Working on 3D sounds like a particularly fun project to me and I don't think I'd mind spending some extra hours on it if need be. Sorry for hitting the list so hard -- SOC was only recently suggested to me and I am really set on contributing to Wine if that's possible. Again, thanks for your support and suggestions. John
Re: Summer of Code applicant with ambition!
On Tue, Mar 30, 2010 at 4:13 PM, John Koelndorfer jkoelndor...@gmail.com wrote: I've done a little bit of research on Direct3D. Having seen how easy the tutorial at http://www.directxtutorial.com/ is, I think I'd like to propose the following: a 3D benchmarking program that would allow users and developers to determine what aspects of WineD3D are the slowest so that they can be improved. My high level idea is that a user would be able to set graphics options (similar to a game -- or maybe automatically test many configurations) and a 3D demo would run. It would time D3D function calls so that we can get an idea for which functions need optimization, report FPS at points in time, and whatever else makes sense as I learn more about it. Ideally that would be part of wine's dxdiag.exe. Windows' has 'Test DirectDraw' and 'Test Direct3D' options, which would be useful to do in wine as well. See also http://bugs.winehq.org/show_bug.cgi?id=14118. -- -Austin
Re: Summer of Code applicant with ambition!
On Wed, Mar 31, 2010 at 12:13 AM, John Koelndorfer jkoelndor...@gmail.com wrote: I've done a little bit of research on Direct3D. Having seen how easy the tutorial at http://www.directxtutorial.com/ is, I think I'd like to propose the following: a 3D benchmarking program that would allow users and developers to determine what aspects of WineD3D are the slowest so that they can be improved. My high level idea is that a user would be able to set graphics options (similar to a game -- or maybe automatically test many configurations) and a 3D demo would run. It would time D3D function calls so that we can get an idea for which functions need optimization, report FPS at points in time, and whatever else makes sense as I learn more about it. Note, I don't want to discourage you but I'm not sure if we should write any benchmark app to be bundled with Wine. When a game is slow it can be due to a lot of factors: - quality of the display drivers, basically only Nvidia's drivers (though AMD is catching up) are well optimized - opengl extensions supported by the display driver, not all drivers support functionality like FBOs, GLSL and other stuff which is needed to run games at good speeds - behavior of the app, if unlucky the app makes calls which are inefficient to emulate (on newer cards, modern opengl extensions can remove some of the limitations and we use such extensions where we can) So when you encounter a 3D performance issue, it is not necessarily a Wine issue. Profiling using a tool like oprofile/sysprof can shine some light on the problem. Typically it is not that a huge part of the time is spent in a specific Wine call though. A lot of CPU time might be spend in display drivers. Whether that is because we are using it in an inefficient way or whether the driver is not well optimized is hard to say because typically drives don't contain debug symbols. I think that a Wine 3D demo is not sufficient to properly test for performance issues. If you want to work in this area, perhaps a more generic 3d testing framework is a better project which uses real games (or demos). Codeweavers uses I believe cxtest to monitor performance regressions in 3dmark 2003, half-life 2 and other apps. I have no idea how robust this framework is. Perhaps it can be improved (or rewritten). We have some basic fps dumping code using WINEDEBUG=+fps which could be used if a game doesn't provide a way to retrieve results. Nvidia (perfkit/perfhud for NV) and AMD drivers offer performance counters which give indications on how busy parts of the GPU are. Perhaps that stuff could be used to improve results. Roderick
[GSoC] IUri Implementations
Hi, my name is Thomas Mullaly and I am a undergraduate in the Computer Science department at Kent State University and I would very much like to participate in this years GSoC. I saw under your project ideas page that the IUri API still needs implemented and I thought that this would be a good project for me, but, before I submit a proposal on it I have a few questions about the project itself. Firstly, on the project page it says that the main goal is to have the IUri interface and CreateUri function implemented, but, on MSDN they also have functions and interfaces for creating/manipulating IUriBuilder's and I was wondering if these were also part of the project goals. If not can they be or would this be to ambitious to have finished by the end of the summer. Secondly (more of a design question), I see that the Uri structure and functions are already stubbed out in the dlls/urlmon/uri.c file and I was thinking for my implementation I would add another BSTR* member to the Uri struct, which will point to the encoded version of the URI (which will be generated during the CreateUri() call). Since most of the functions that interact with the IUri return components of the URI (e.g. scheme, host, query, etc.) I was thinking about adding more data members to the Uri struct which store the location in the encoded Uri string where each component exists (or -1 if it does not exist) and by doing this the runtimes of the IUri functions will be reduced since the function will already know where to look inside the encoded string for the component it needs. A drawback to this design is that each Uri struct will be bloated with a decent amount of ints which may or may not be used depending on the type of the URI that the IUri represents. The second approach I was thinking of is to not store any locations inside the Uri struct and to compute them on the fly every time the IUri is queried for one of its components, this would result in a smaller memory footprint of the Uri structure but will increase the runtimes of all the functions that access the URI. I was wondering if anyone might have suggestions for which way they think might be better. Any input will be greatly appreciated! -Thomas Mullaly
Re: Summer of Code applicant with ambition!
snip thread Sorry this is a little off topic from D3D but maybe what the OP is looking for. I'm not sure how easy it is but .net 3.5 sp1 is currently a blocker for several high profile games that would otherwise work well with Wine, and many others that may work. .net needs to install correctly and function well enough so that generic .net game lunchers run and (importantly) Games for Windows Live runs and authenticates. GFWL is what many of these games rely on and it is currently blocked by .net so it's unknown how well it runs under Wine but it does install properly. This maybe suited to a GSoC project and in my opinion would have the greatest positive outcome for gamers. Edward
Re: [GSoC] IUri Implementations
On 3/31/2010 02:57, Thomas Mullaly wrote: Hi, my name is Thomas Mullaly and I am a undergraduate in the Computer Science department at Kent State University and I would very much like to participate in this years GSoC. I saw under your project ideas page that the IUri API still needs implemented and I thought that this would be a good project for me, but, before I submit a proposal on it I have a few questions about the project itself. Hi, Thomas, and welcome. Firstly, on the project page it says that the main goal is to have the IUri interface and CreateUri function implemented, but, on MSDN they also have functions and interfaces for creating/manipulating IUriBuilder's and I was wondering if these were also part of the project goals. If not can they be or would this be to ambitious to have finished by the end of the summer. Right, a complete IUri with corresponding tests will be enough for a summer project I think. After a brief look at IUriBuilder I think it doesn't depend on a IUri implementation details so much. For IUriBuilder one way I see is to track changed properties and store only new data, using unchanged properties from supplied IUri, but this needs some tests (does it keep reference for IUri for example or not). Secondly (more of a design question), I see that the Uri structure and functions are already stubbed out in the dlls/urlmon/uri.c file and I was thinking for my implementation I would add another BSTR* member to the Uri struct, which will point to the encoded version of the URI (which will be generated during the CreateUri() call). Since most of the functions that interact with the IUri return components of the URI (e.g. scheme, host, query, etc.) I was thinking about adding more data members to the Uri struct which store the location in the encoded Uri string where each component exists (or -1 if it does not exist) and by doing this the runtimes of the IUri functions will be reduced since the function will already know where to look inside the encoded string for the component it needs. A drawback to this design is that each Uri struct will be bloated with a decent amount of ints which may or may not be used depending on the type of the URI that the IUri represents. The second approach I was thinking of is to not store any locations inside the Uri struct and to compute them on the fly every time the IUri is queried for one of its components, this would result in a smaller memory footprint of the Uri structure but will increase the runtimes of all the functions that access the URI. I was wondering if anyone might have suggestions for which way they think might be better. You could use dynamic array for that or a list with a Uri_PROPERTY value as a key for example and a data as an offset and length. Another way is to compute each property offset only when it's requested and store it. An obvious bad case for that is a long uri. So probably one pass property computation while building IUri instance is not bad. Waiting for Jacek comments. Any input will be greatly appreciated! -Thomas Mullaly
Re: Summer of Code applicant with ambition!
On Tue, Mar 30, 2010 at 6:11 PM, Edward Savage epss...@gmail.com wrote: snip thread Sorry this is a little off topic from D3D but maybe what the OP is looking for. I'm not sure how easy it is but .net 3.5 sp1 is currently a blocker for several high profile games that would otherwise work well with Wine, and many others that may work. .net needs to install correctly and function well enough so that generic .net game lunchers run and (importantly) Games for Windows Live runs and authenticates. GFWL is what many of these games rely on and it is currently blocked by .net so it's unknown how well it runs under Wine but it does install properly. This maybe suited to a GSoC project and in my opinion would have the greatest positive outcome for gamers. Edward Edward seems to know what I'm after. :-) As I mentioned originally, I'm a gamer and so that's where I'd like to lend my coding arm. If .net is doable, I'd certainly look into that too. Note, I don't want to discourage you but I'm not sure if we should write any benchmark app to be bundled with Wine. When a game is slow it can be due to a lot of factors: - quality of the display drivers, basically only Nvidia's drivers (though AMD is catching up) are well optimized - opengl extensions supported by the display driver, not all drivers support functionality like FBOs, GLSL and other stuff which is needed to run games at good speeds - behavior of the app, if unlucky the app makes calls which are inefficient to emulate (on newer cards, modern opengl extensions can remove some of the limitations and we use such extensions where we can) So when you encounter a 3D performance issue, it is not necessarily a Wine issue. I certainly agree here 100% -- however, my own previous experiences have led me to conclude that there are Wine performance deficiencies *somewhere* (maybe not necessarily D3D, but it seems the likely candidate). See e.g. Warcraft 3 and World of Warcraft. Both of these games have Direct3D and OpenGL modes. Running each game in Wine (at least in my testing from several months to a year ago) D3D was anywhere from 40-60% slower than OpenGL mode. I'd be happy to test with the latest Wine, too. The point is, all things being held constant, calls that had to go through WineD3D were much slower. That's where the spirit of my proposal came from, anyways. Now, you might say does Wine need some sort of benchmarking? That's debatable. Maybe it could be a part of dxdiag? My goal for this proposal was to create something that developers could use to assess performance deficiencies, or that end users (maybe) could use to figure out what type of effects ought to be turned off/down on their systems. Essentially, answer the question what's making my FPS drop? Is it AF, AA, specular lighting, HDR? There's been a lot of feedback so far (thanks!) So far, the projects I'd like most are roughly: * Get .net 3.5 working * Implement dxdiag * DirectShow/Gstreamer * The Direct3D - Conformance / Performance / Interactive tests given @ http://wiki.winehq.org/SummerOfCode#head-8d0895f237c9c3579ffe4282412bbbf2c8cd019b Again, many thanks for all the helpful feedback. I look forward to (hopefully) being able to work with you all in the near future. :-) John
Re: [GSoC] IUri Implementations
You could use dynamic array for that or a list with a Uri_PROPERTY
value as a key for example and a data as an offset and length. Another
way is to compute each property offset only when it's requested and
store it. An obvious bad case for that is a long uri. So probably one
pass property computation while building IUri instance is not bad.
I like the idea of making a lightweight data structure which stores the
offset and length for each component property. I'd imagine it would look
something like this:
typedef struct {
DWORD offset;
DWORD length;
} UriComponent;
Although it becomes a little more tricky on how to store the
UriComponents, but, I have a few ideas if anyone has any suggestions.
I do like the idea of using an array inside the Uri struct to store the
UriComponents but not all of the values in the Uri_PROPERTY enum
actually mean anything (at least thats what I have gathered from reading
the MSDN docs), like the Uri_PROPERTY_STRING_START and the
Uri_PROPERTY_STRING_LAST are just there to say all the enum values
between = START and = LAST correspond the string components of the URI.
So I'm thinking the Uri struct should have a constant size array of
UriComponents of length Uri_PROPERTY_STRING_LAST (which would be 15..
correct me if I'm wrong).
So it would look something like...
typedef struct {
/** The other stuff */
BSTR *uri;
UriComponents components[15];
} Uri;
and then for the GetPropertyBSTR(BSTR *component, Uri_PROPERTY prop)
function you could just have something like.
if(prop = Uri_PROPERTY_START prop = Uri_PROPERTY_LAST) {
UriComponent comp;
comp = uri-components[prop];
/** Parse the component out */
}
And that should get you the necessary offsets and lengths for the
component you need.
I also like the idea suggested before using a one-pass solution to find
everything when the Uri is constructed.
Thank you for the quick responses and suggestions, I hope to have a
proposal ready in the next few days.
