September 2007 - Wine-devel

Re: make_makefiles: ignore .DS_Store files
by Alexandre Julliard 11 Sep '07

11 Sep '07

Emmanuel Maillard <mahanuu(a)free.fr> writes: > From b298a599f2b0eb5b8d7f2092573aba28755001d7 Mon Sep 17 00:00:00 2001 > From: Emmanuel Maillard <mahanuu(a)free.fr> > Date: Sun, 2 Sep 2007 12:42:16 +0200 > Subject: [PATCH] - ignore .DS_Store files You should put that in your global ignore file, the .DS_Store files are not created by the build process so they don't belong in .gitignore. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WineD3D: PBO support 2/2
by Stefan Dösinger 11 Sep '07

11 Sep '07

Am Dienstag, 11. September 2007 10:25:28 schrieb Roderick Colenbrander: > Hi, > > This patch adds PBO support for dynamicly locked textures. It greatly > improves performance of games that use render target locking a lot. It looks good to me, here are some suggestions for further improvements in further patches(this patch is good for the start). The locking flag passed to LockRect could be forwarded to GL. D3DLOCK_DISCARD and D3DLOCK_WRITEONLY(ddraw only) would be GL_WRITE_ONLY, D3DLOCK_READONLY GL_READ_ONLY. However, we have to take care about the upside down swap for render target locking. D3DLOCK_DISCARD can be implemented(appart of the surface beeing writeonly) by calling glBufferData with a NULL pointer. This tells gl that the old data can be thrown away. This allows the driver to further optimize the map. e.g. if it is a texture that is still used for rendering in some pending calls, it can duplicate the buffer and doesn't have to wait for the rendering to finish. It will have to be tested if that really helps performance. I tried it for vbos, and it made things noticeably worse. Binding the pbo to 0 after each operation is a good idea for a start, but shouldn't be done in the long term in my opinion.

1 0

settlers 3 and dib engine
by Skrzynka 10 Sep '07

10 Sep '07

Hi, I'm trying to get Settlers 3 to run on Wine. After fixing some race condition (seems like the thread calling WaitForXXXObject was giving up time-slice too early after the call) it seems that the only problem left is very slow text output. What I could understand from the forum archives is that with no DIB engine, the rendering into a DC causes copying of the bitmap to/from server (is that correct?). I'd like to contribute to the DIB engine if it's possible/needed, so I'd like to ask about a few things. There were some discussion recently about an implementation of DIB engine by Jesse Allen - what is the status of DIB engine? I compiled winedib.drv but ExtTextOut function is missing there and overall there are regressions visible when running Settlers 3 (wrong colors, no text at all). Which docs/urls/sources would you recommend to read to get some quick introduction to the DIB engine? Which particular functions are making current impl slow? Or, in general: where to start? Sorry for any silly questions... Thanks & regards Piotr -- ----- AlphaNet - najtaniej w sieci! -------- Odnowienia domen w rewelacyjnych cenach! .pl - 65 zl, .com.pl - 50 zl, reg - 20 zl http://www.domeny.alpha.pl --------------------------------------------

4 8

Re: ntdll: Do not segfault with snoop for files with a broken exporttable
by Dmitry Timoshkov 10 Sep '07

10 Sep '07

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > ntdll: Do not segfault with snoop for files with a broken export table > + /* Check for files with broken exports */ > + if (exports->Characteristics || > + exports->MajorVersion || > + HIWORD(exports->NumberOfFunctions) || > + HIWORD(exports->NumberOfNames)) { > + WARN_(snoop)("snoop disabled for bad module %p: 0x%x, %u, 0x%x, 0x%x\n", hmod, > + exports->Characteristics, exports->MajorVersion, > + exports->NumberOfFunctions, exports->NumberOfNames); > + return; > + } > + > TRACE_(snoop)("hmod=%p, name=%s\n", hmod, name); It's still helpful to see the line "hmod=%p, name=%s\n" in the log before an error message. -- Dmitry.

2 1

Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (improved, fixes bug #5877)
by Dmitry Timoshkov 08 Sep '07

08 Sep '07

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > As suggested by Dmitry the table id is now a symbolic constant. However > I didn't included the tttags.h but defined the constant myself as I see > that every freetype header is checked by configure and included only if > it is available. Thus in case it is not available we would either need > an #ifdef in AddFileToList (what IMHO wouldn't be nice) or in such a > case define the symbol ourselfs. But if we will need to define the > symbol then why to include the header? > +#define WINEENG_SFNTTAG_CFF 0x43464620 /* stores the outline for Type1 OTF fonts */ This is not what I suggested. Using a macro like FT_MAKE_TAG makes this much more readable. WINEENG_SFNTTAG_CFF doesn't follow any macro naming conventions in freetype.c, I'd suggest to use the same name as FreeType has (TTAG_CFF) instead, perhaps inside of #ifdef guard if including tttags.h is much hassle. Although including tttags.h and using #ifdef before defining TTAG_CFF is much more clean IMO. -- Dmitry.

1 0

[PATCH 2/3] wininet: Use parent/child handle framework to track parent/child handle relationships.
by Misha Koshelev 08 Sep '07

08 Sep '07

Jacek Caban wrote: > Hi Misha, > > Misha Koshelev wrote: > > We have a lot of parent/child relationships in wininet that are addressed on an individual basis. > > Now we can just address them within the framework since we need that framework for closing handles > > too. The only thing I don't like is that we have to make lots of casts now, but it doesn't really make > > much sense to me to store the "parent" object handle in two different places. > > Sorry for late response. > > This patch reverses what I've done some time ago. There is no reason to > have parent object in header - you need only a child list to handle > closing handles. Also casts make the code much less readable. > > Thanks, > Jacek Ok, that sounds fair. I didn't really like the casts either, that was my biggest problem with this patchset. I am leaving the country tomorrow for 9 days but will change the patches/resubmit as you suggested after I come back. Thanks for your comments. Misha

1 0

Re: [PATCH 2/3] wininet: Use parent/child handle framework to track parent/child handle relationships.
by Jacek Caban 08 Sep '07

08 Sep '07

Hi Misha, Misha Koshelev wrote: > We have a lot of parent/child relationships in wininet that are addressed on an individual basis. > Now we can just address them within the framework since we need that framework for closing handles > too. The only thing I don't like is that we have to make lots of casts now, but it doesn't really make > much sense to me to store the "parent" object handle in two different places. Sorry for late response. This patch reverses what I've done some time ago. There is no reason to have parent object in header - you need only a child list to handle closing handles. Also casts make the code much less readable. Thanks, Jacek

1 0

Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (fixes bug #5877)
by Dmitry Timoshkov 07 Sep '07

07 Sep '07

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > As I wrote in Bugzilla for Photoshop to work with Type1 fonts after > applying this patch one needs to reinstall Photoshop in a clean > wineprefix - it seems that Photoshop caches some font data. > + /* check for the presence of the 'CFF ' table to check if the font is Type1 */ > + tmp_size = 0; > + if (pFT_Load_Sfnt_Table && !pFT_Load_Sfnt_Table(ft_face, 0x43464620, 0, NULL, &tmp_size)) > + { > + TRACE("Font %s/%p is OTF Type1\n", wine_dbgstr_a(file), font_data_ptr); > + face->ntmFlags = NTM_PS_OPENTYPE; > + } Please use a symbolic name instead of 0x43464620. FreeType provides TTAG_CFF, or you can define it on your own using FT_MAKE_TAG. -- Dmitry.

1 0

Kudos - Fireworks 8 working better...
by Dan Kegel 07 Sep '07

07 Sep '07

http://www.5thpercentile.com/devBlog/archives/2007/09/wine_just_got_t.html and http://appdb.winehq.org/appview.php?iVersionId=4149&iTestingId=15163 both say that wine-0.9.44 really improves Adobe Fireworks. Yay! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: wined3d: add WINED3DPRESENT_INTERVAL_ONE flag (fix bug 9584)
by Stefan Dösinger 07 Sep '07

07 Sep '07

Am Freitag, 7. September 2007 18:29:02 schrieb Louis. Lenders: > I added this initially as a hack to get mame running, but what i understood > from discussion on IRC, there's no way we can check the graphics card's for > this capability now, and adding it as default (so without checking) would > be rather harmless. Short answer: Patch is ok with me Long answer: We can check if opengl supports vsync(which is what this flag does). WineD3D implements vsync using GLX_SGI_video_sync. So if this extension is supported, we should set the flag. If it is not supported, do not set it. Our WGL implementation does not forward the GLX extension yet, so we do not support vsync at the moment, so setting this flag means essentially lying to the app. However, I think it is safe to pretend vsync support. The worst that may happen is that the game renders with a higher framerate, and the hardware consumes more power instead of beeing idle. I think both cases are better then not running the game at all. There's one game which runs into internal race conditions if vsync does not work(need for speed 3), but that game doesn't even care to check that flag.

1 0