wine-devel April 2006

wine-devel@winehq.org

176 participants
334 discussions

Fwd: Wined3d/OpenGL question
by James Trotter 04 Apr '06

04 Apr '06

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Apr 4, 2006 8:16 PM Subject: Re: Wined3d/OpenGL question To: Jason Green <jave27(a)gmail.com> On 4/4/06, Jason Green <jave27(a)gmail.com> wrote: > > I may be barking up the wrong tree here, but I'm trying to debug the > cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in > drawprim.c (line 1251). This is for Civilization 4 using both > hardware vertex & pixel shaders. I've only noticed this error when it > is passed GL_TRIANGLES with a large number of vertices. > > Here's a sample output with a little extra debugging info, and cleaned > up a little: > > trace:d3d_draw:primitiveToGl TRIANGLES > trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, > number of vertices1156 > trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, > number of vertices1156 > ... > trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader > trace:d3d_draw:drawPrimitiveDrawStrided > glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok > drawprim.c / 1846 > trace:d3d_draw:drawPrimitiveDrawStrided > glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 > trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) > fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from > glDrawRangeElements @ drawprim.c / 1251 > > Often, a series of these errors will result in an unhandled exception > in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 > kernel). > > I read up on the glDrawElements() function and it refered to the > GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call > that function, it returns 4096, and the number of vertices that it's > trying to pass is larger than that. I've tried doing a min() of the > max and the actual # of vertices, but the results are the same. > > So, the question is: Could this be one of the causes of the graphical > glitches I'm seeing? I can toy around with these functions all day, > but I don't really understand them all that well. Does that routine > need to be reworked to split up a D3DPT_TRIANGLELIST into multiple > calls if the calculated number of vertices/indices is too high for the > user's graphics card? Or, am I way off base thinking this has any > bearing on my real issues? > > Thanks, > Jason > > > GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES are just performance hints, and not actual limits to how many vertices or indices that the driver can handle. From http://pyopengl.sourceforge.net/documentation/manual/glDrawRangeElements.3G… : "Implementations denote recommended maximum amounts of vertex and index data, which may be queried by calling glGet with argument GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES. If end - start + 1 is greater than the value of GL_MAX_ELEMENTS_VERTICES, or if count is greater than the value of GL_MAX_ELEMENTS_INDICES, then the call may operate at reduced performance. There is no requirement that all vertices in the range [start,end] be referenced. However, the implementation may partially process unused vertices, reducing performance from what could be achieved with an optimal index set." Also, "GL_INVALID_OPERATION is generated if glDrawRangeElements is executed between the execution of glBegin and the corresponding glEnd."

1 0

wine / fontforge regression
by Molle Bestefich 04 Apr '06

04 Apr '06

Hello, This patch from Mar 9: http://www.winehq.org/pipermail/wine-cvs/2006-March/021502.html causes all applications run with Wine to continually emit: err:font:ReadFontDir Can't open directory "/usr/local/bin/../lib/../share/wine/fonts/" when fontforge isn't installed. Also, take a look at the path above. It's relative to '/usr/local/bin', ok - but why the double descend into the parent directory? The "../lib" seems completely redundant with the "../share" coming right after it. Regards

8 13

Re: compile error
by Tom Spear 04 Apr '06

04 Apr '06

On 4/4/06, MF <mforcada(a)freesurf.ch> wrote: > > Hi Tom, > > After make depend, last lines give this message: > quote > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.UrlAln.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > unquote Aha! Ok, so make dep and make are failing before they are able to build any of the tools like winecfg and wineprefixcreate... That is due to your 64-bit libraries being installed in the default location, and your 32-bit ones being installed elsewhere.. Do you happen to have a /usr/lib32 directory? If so, try doing the build like this: make distclean LDFLAGS=/usr/lib32 ./configure make dep make sudo make install and then do the wineprefixcreate and run winecfg.. Let us know if you have any problems after that.. Of course if you do have a lib32 dir, but it is not /usr/lib32, substitute the path to your lib32 dir where I put /usr/lib32 (it shouldn't be just /lib32).. Of course someone on the list could tell you the exact path to the directory if you would be so kind as to tell us what distro you are using. :-) Tom

1 0

re: richedit20: Implement EM_FORMATRANGE
by Dan Kegel 04 Apr '06

04 Apr '06

Hi Troy, any chance you can also provide a conformance test, however trivial? (Also, from reading http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=973… http://support.microsoft.com/default.aspx?scid=kb%3Ben%3B129860 http://www.codeproject.com/printing/richeditprint.asp I gather that some but not all apps will also require EM_DISPLAYBAND to make use of this, right? Just curious.) Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

compile error
by MF 04 Apr '06

04 Apr '06

Hi, System: Dell Power Edge 830, Intel Dual Core, Linux Ubuntu 5.10, 64 bits version Tried to compile Wine with the ./tools/wineinstall as per recommended procedure in readme file, from sources package downloaded with apt-get build-dep wine and apt-get --build source wine wich did not go 100% well...: quote Reading package lists... Done Building dependency tree... Done Need to get 13.5MB of source archives. Get:1 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (dsc) [1209B] Get:2 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (tar) [13.5MB] Get:3 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (diff) [47.0kB] Fetched 9537kB in 35s (268kB/s) dpkg-source: extracting wine in wine-0.9.10~winehq1 dpkg-source: unpacking wine_0.9.10~winehq1.orig.tar.gz dpkg-source: applying ./wine_0.9.10~winehq1-2.diff.gz dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.10~winehq1-2 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot dh_testroot: You must run this as root (or use fakeroot). make: *** [clean] Error 1 Build command 'cd wine-0.9.10~winehq1 && dpkg-buildpackage -b -uc' failed. E: Child process failed end quote The directory "wine-0.9.10~winehq1" was created OK and the package source seemed to be there. So I tried "./tools/wineinstall" and got the following message: quote configure: creating cache config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Configure failed, aborting install. end quote re-did the whole thing after clean up and tried the dpkg command in sudo and got quote ~/wine-0.9.10~winehq1$ sudo dpkg-buildpackage -b -uc dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.10~winehq1-2 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot rm -f build-stamp # Add here commands to clean up after the build process. /usr/bin/make distclean make[1]: Entering directory `/home/formig/wine-0.9.10~winehq1' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/formig/wine-0.9.10~winehq1' make: [clean] Error 2 (ignored) #-/usr/bin/make -C documentation clean dh_clean debian/rules build dh_testdir # Add here commands to configure the package. CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... yes checking for x86_64-linux-gnu-gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [config.status] Error 77 unquote Seems to be an error with my C compiler ? GCC IS 4:4.0.1-3 I attach config.log for more details. Any idea ? With kindest regards, Miguel

4 5

Re: advpack: Rewrite get_parameter so that it can handle empty parameters [RESEND]
by Alexandre Julliard 04 Apr '06

04 Apr '06

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Rewrite get_parameter so that it can handle empty parameters. You are still parsing the whole string for every parameter, this is O(n^2) which isn't very nice. What you want is a strtok-style function to retrieve parameters sequentially. -- Alexandre Julliard julliard(a)winehq.org

1 0

Pegasus Mail via Wine
by James E. Lang 04 Apr '06

04 Apr '06

I have been using Pegasus Mail via Wine for nearly two years. Before that I used Pegasus Mail on a Win98 system for several years. Since Wine officially entered Beta category in late 2005, I have tried most of the releases (starting with 0.9.3). Pegasus functioned quite well with Wine Versions 0.9.3, 0.9.5, 0.9.6, 0.9.7, & 0.9.8. Wine Version 0.9.4 was unusable. Wine Versions 0.9.9 and 0.9.10 both sent Pegasus a signal to shut itself down when the message composition window got closed. As Rein Klazes wrote on 11 Mar 06 @ 06:20 re: user32: Handle WM_ENDSESSION in DefWinProc(): > On Fri, 24 Feb 2006 14:29:45 -0600, you wrote: > > Author: Francois Gouget <fgouget(a)codeweavers.com> > > Date: Fri Feb 24 15:34:09 2006 +0100 > > > > user32: Handle WM_ENDSESSION in DefWinProc(). > > DefWinProc() should call PostQuitMessage() on WM_ENDSESSION if the > > shutdown is proceeding. > > Hi Francois, > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. > Here is a part of SPY++ log when run under win2000, when I close the > edit new mail dialog ... I don't know whether this is fixed in Wine Version 0.9.11 since I cannot get Pegasus Mail to perform any useful function with that version of Wine. With Wine Version 0.9.8 Pegasus Mail would load on my computer and display my list of e-mail folders within 30 seconds. With Wine Version 0.9.11 Pegasus Mail still does not display the folder list after 15 minutes. Pegasus Mail's startup window *does* display for the proper time interval. "Technical" Observations: When I use Wine Version 0.9.8 and use KDE System Guard to view the running processes I see that the process that is running the bash shell that runs Pegasus Mail has one Wine related offspring process ("Wine-preloader") and that offspring uses about 598,000 bytes of RAM. When I use Wine Version 0.9.11 there is that same process but it in turn has an offspring process of its own (also "Wine-preloader") which uses about 41,500 bytes of RAM. During the time that Wine was failing to display the normal things for Pegasus Mail I noticed that the value of VmRss (resident virtual memory?) increased in very small increments (usually 8 bytes at a time) two or three times a minute. The total VmSize (Virtual Memory Size?) value did not change. It is remotely possible that given enough time (measured in hours maybe) that Pegasus Mail would have finally displayed something useful. What I'm trying to say is that I have not been able to use any version of Wine after 0.9.8 to support Pegasus Mail and I'm trying to pass along a description of what I see. I have no debug code activated and do not know what debug options would be appropriate. -- Jim

1 0

[opengl] Another possible fix for the BadMatch error
by Leon Freitag 03 Apr '06

03 Apr '06

Someone mentioned earlier that the code in wgl.c in DescribeDrawable() violates the GLX specification and therefore causes bogus return values for the visualid. However this code has been already present before the regression, but worked somehow. So the regression can't be caused by this violation. I tried to correct this violation by calling glXChooseFBConfig and then glXGetChooseConfigAttrib, as suggested in the spec, and glXChooseFBConfig returns NULL for the appropriate FBCONFIG_ID. However the problem seems to be in getting Drawable which is then passed to DescribeDrawable. The VisualID of the Drawable isn't needed at all, since before calling the glXMakeCurrent, we just want to know if the context visualid differs from visualid of Wine desktop. This one-liner should fix the BadMatch errors. Tested on Warcraft 3. http://winehq.org/pipermail/wine-devel/2006-March/thread.html ------ diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c index c7d3147..e9046ca 100644 --- a/dlls/opengl32/wgl.c +++ b/dlls/opengl32/wgl.c @@ -551,7 +551,7 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, draw_vis_id = describeDrawable(ctx, drawable); ctx_vis_id = describeContext(ctx); - if (-1 == draw_vis_id || (draw_vis_id == visualid && draw_vis_id != ctx_vis_id)) { + if (visualid != ctx_vis_id) { /** * Inherits from root window so reuse desktop visual */ Please test this patch and report if it works. If it works fine (and doesn't introduce any regressions) then I'll submit it to wine-patches. Leon

3 2

Re: winebuild: Add an "x86_64" flag
by Alexandre Julliard 03 Apr '06

03 Apr '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Add an "x86_64" flag in winebuild so we can export 64-bit-only > functions in a 64-bit build. Are there really enough functions that would need this to justify adding a new flag? -- Alexandre Julliard julliard(a)winehq.org

2 2

AppDB email address obfuscation
by n0dalus 03 Apr '06

03 Apr '06

Hi, I am concerned that the email addresses on the appdb are too easily harvestable. Is there a reason no effort seems to be made to hide the email addresses of users on there? Also, when getting a notification of a post, you can see everyone's email addresses in the To: field. Should these be Bcc? Just curious, n0dalus.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2006