September 2002 - Wine-devel

Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527)
by Uwe Bonnes 28 Sep '02

28 Sep '02

Hallo, the Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527) in wine/dlls/ddraw/mesa_private.h unconditional inclused GL/gl.h and GL/glx.h. On my Suse V8.0 system ( with the mesa package installed and the mesa-devel package not installed) this leads to: make[2]: Wechsel in das Verzeichnis Verzeichnis »/home/bon/tmp/wine/compile/wine-realclean/wine/dlls/ddraw« gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTR ANT -I/usr/X11R6/include -o dsurface/main.o dsurface/main.c In file included from dsurface/main.c:27: mesa_private.h:32: GL/gl.h: Datei oder Verzeichnis nicht gefunden mesa_private.h:33: GL/glx.h: Datei oder Verzeichnis nicht gefunden make[2]: *** [dsurface/main.o] Fehler 1 Probably it's a bad idea to only install mesa and not mesa-devel, but I think wine should cope with this situation or at least warn the user about that. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: A problem reading configuration file
by Sylvain Petreolle 28 Sep '02

28 Sep '02

Me too. I made some programs with assembly under MS-DOS in the 90s before switching to Linux ;) > I think its normal. Findfirst finds the first entry, and findnext > returns only > the next :) > I'm sure it works that way. I have tried to check that in some > documentation, > but if I remember right then I have used those in something like > Borland > Delphi at the university. But I dont have Delphi at home... > > If that is ok, then do you have some idea, what could be the problem? > There was a patch applied few days ago on findnext... perhaps it's it. http://www.winehq.com/hypermail/wine-patches/2002/09/0243.html ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: A problem reading configuration file
by Sylvain Petreolle 28 Sep '02

28 Sep '02

Remarque : message transféré en pièce jointe. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Fix for msvcrt sscanf/swscanf
by Uwe Bonnes 28 Sep '02

28 Sep '02

>>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: Jukka> Wine msvcrt sscanf and swscanf implementations incorrectly expect Jukka> strings to end with EOF. This crashes some applications which did Jukka> work with older versions of Wine that just forwarded msvcrt Jukka> sscanf to libc sscanf. Jukka> Changelog: Functions sscanf and swscanf now expect strings to be Jukka> terminated with null (0) instead of EOF (-1). I asked some weeks ago about the test framework for msvcrt, but nobody jumped on the waggon. The mix of msvcrt and libc was something I couldn't do myself. Perhaps somebody can come up with someting. It sure is important to codify findings like Jukkas. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: [Controversial] Developper only CVS sandbox
by Dan Kegel 28 Sep '02

28 Sep '02

I've strongly opposed to using ClearCase for Wine development :-) I'm also somewhat opposed to CVS. The big problem with CVS is that it makes it *too* easy to contribute changes, and too hard to disentangle changes later when trying to contribute them back to the main tree. (This kind of thing has caused huge nightmares in the past.) So all you folks that feel that creating and posting patches is hard -- the payoff is *each change is much easier to peer review*. That makes for much higher quality code! If you really want to use a CVS-like system, go have a look at Bitkeeper. It's free for open source projects, and it is the only source code control system that doesn't make it hard to disentangle changes later. - Dan

2 1

Re: RFC: Winsock todo's
by Dan Kegel 28 Sep '02

28 Sep '02

Martin Wilck wrote: > Although I had a relevant part in implementing the asynchronous IO in > winsock, I am not quite content with it because it is not really > asynchronous. And not really high-performance, I bet (though I wouldn't know, I haven't looked at the code or tested it). > Alexandre is against using threads. Me, too. glibc uses threads to emulate aio, and the performance is poor. On platforms that natively support AIO, I bet you *really* want to implement Wine AIO using Posix AIO if you can. > On Linux at least, Ben > LaHaise's asyncio can be expected to become part of the > 2.6 kernel series, and if that happens the wine asynchronous IO > functionality should be rewritten to use the asyncio API on systems that > support it. Yes. Exactly. > (I still havent't figured out whether aio will support > sockets, though). It will. SGI's kaio does already, and Ben's will support it when he's finished. That should give good performance. - Dan p.s. Looks like the threads implementation for the 2.6 kernel will rock, too. See http://www.kegel.com/c10k.html#threaded (Somebody remind me why Wine has its own threads implementation again? Is it because the semantics are too different from Posix threads?)

1 0

Status of *ongoing* wine improvements?
by Dan Kegel 28 Sep '02

28 Sep '02

The To-Do list Steven Edwards is putting together looks like a nice menu of Things That Need To Be Done But Have Not Been Started Yet. A similar list, of ongoing work, might be useful in a different way. Check out http://www.kernelnewbies.org/status/ It has a number of nice features: * status of each proposed enhancement (planned / started / alpha / beta / ready / merged) * each line is a link to a wine-devel post or web page describing the proposed work * each line has the names of people actually working on them * items changed since last week are bold * only items expected to be finished before the feature freeze for the next release are included This list might be pretty short for Wine, but it'd be a nice way of tracking progress. - Dan

1 0

Re: DIB engine
by Gavriel State 28 Sep '02

28 Sep '02

Ove Kaaven wrote: > Well, here is the DIB engine that a couple of people at TransGaming > (mostly David Hammerton, I think) did some work on a while ago, I finally > got around to review it and make sure it compiles against the current > ReWind (though perhaps it needs a few tweaks to compile against Wine). > It's not all that complete by any means, but we wanted to get it out > there, so feel free to comment on it (or even apply it to Wine if it's > good enough). Primary attribution should go to Jonathan Meunier, a co-op student who worked with us earlier this year. David Hammerton, Peter Hunniset, and I all assisted with it to one degree or another. If there is any general interest in pursuing DIB Engine work, we would of course appreciate it if developers are willing to license their contributions to ReWind. Ove seems to have forgotten to include the documentation, which includes some nice background on DIB issues in general, and should go into the documentation directory. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com TRANSGAMING TECHNOLOGIES DIB ENGINE DOCUMENTATION (GDI RENDERER) Copyright (c) 2002 TransGaming Technologies Inc. SCENARIO -------- The Win32 API allows for a graphics format called DIBSections. DIBSections allow the application to write to the image in two ways: Direct Access and through GDI. Direct Access means that the application can simply write whatever data it likes to the image - the application has a pointer to the physical image bits, and can write to this with no problem. In ReWind's X11 Driver we can emulate this kind of access by using XImages. The GDI access allows the application to do a whole heap of extra stuff to its graphics, including special rendering such as lines, polygons, ellipses and so on. ReWind emulates such calls through the use of X11's renderer by using XPixmaps. With a DIBSection, the Win32 API allows both of these features to be used on a single image. This is currently supported by ReWind, but it can be slow at times and rather 'hacky'. This is achieved using the following method: o When a DIBSection is created, space is allocated for the application (where the application can directly write to). This is also an XImage. o Another XImage is created for 'conversions' (see depth conversion). o An XPixmap (which is a X Drawable) is created on the X Server. o The application-side data is memory protected to no access. Now, ReWind's X11 driver keeps track of which "image" is most up-to-date, it has 3 mods: gdimod, appmod and insync. (There is actually a 4th mod called 'auxmod' which is used for auxiliary tasks such as OpenGL). These mods represent different states, as follows: o gdimod means that the XPixmap has the most up-to-date version of the image, it was written to last. o appmod means that the application has the most up-to-date version, it has written the image data manually. o insync means that the both the images are up-to-date, they contain the same data. The application can then write into the memory which it is given direct access to, but when it tries to do so a segmentation fault is raised because the memory has been protected. This segmentation fault is caught by ReWind which it recognizes as an attempt to access the application data of a DIBSection. A "coercion" is now called on this DIBSection. If the DIBSection is in gdimod at the time of the segmentation fault, a copy is necessary before we allow the application to write to the DIBSection. The Pixmap is then fetched from X and placed into the XImage in the correct format. The Application is now free to write to the image data, the DIBSection is placed in appmod. A similar thing happens when a GDI painting function gets called, we ensure that the DIBSection is in gdimod (The Pixmap is up-to-date). X is then free to to its rendering. A Problem: Depth conversions and X Limitations: There are many other "nicer" ways that could, in theory, work. With some extensions X is able to render into a XImage, we could use Shared Memory Pixmaps or we could work on getting the upcoming on-the-fly X depth changing into XFree86 4.3. Unfortunately none of these are complete enough to work for our needs. One of the big things that many of them lack is palette support (8bit graphics). So, presently XPixmaps must be in the depth format that the users current X is running at. But the application only knows one way to draw to the DIBSection: The format it requested. This means we have to do depth conversions when we do our coercions from one format to another. This can be slow, particularly if we are constantly doing the conversions. One of the worst cases is when the application requested 8 bit paletted mode and X is running in 24bit mode. A copy from appmod to gdimod/insync involves indexing each color and placing it in the new XImage, then sending it over to X. A copy in the other direction involves a reverse palette lookup, for each pixel we have to cycle through the 256 possible colors and find the correct index for them. This gets quite harsh on X when doing a large image, for example take a 1024x768 screen at 24bits (padded to 32bits): That becomes a 3 megabyte copy every time, doing that often can really slow things down. DIRECT DRAW USAGE ----------------- One important use of DIBSections is DirectDraw. Although games may not explicitly use DIBSections themselves, ReWind does. In Rewind a DirectDraw surface is basically a DIBSection. This is because DirectDraw can be used much like a DIBSection: The application can draw directly to it, yet Win32 can still do GDI rendering to it. For this reason many Win32 DirectDraw applications suffer serious performance problems as a result of DIBSections. Several games you may wish to look at are StarCraft (not too bad because it uses a 640x480 surface) and Age of Empires 2 (badly effected, as it uses a 1024x768 paleted surface). A BETTER SOLUTIONS: THE DIBENGINE --------------------------------- A better solution for this problem has constantly been discussed and is the DIB Engine. The purpose of the DIB Engine is to implement a fully functional GDI renderer capable of doing all the things X is presently used for, plus others which are currently unimplemented in any way. The DIB Engine would basically be able to take care of all GDI rendering when needed itself by rendering into the application memory (at the depth requested by the application). This would save on the copying backwards and forwards most of the time. (Although we would still have the copy to X when blitting to the primary surface). A DIBEngine has to implement a lot of functionality and must include the raw functions to render things like lines, polygons, ellipses and so on to the image. Another functionality of a DIBEngine should be to understand the ROP modes given to the various blitting functions. ROP stands for Raster Operations and is a method by which an application can make customize a blit fairly extensively. In Win32 there are two types of ROP's: Binary ROP's and Tenerary ROP's. Tenerary ROP's allow for up to 256 different types of blitting and are described by a string in reverse polish notation. An example Tenerary ROP could be DPSoo which is described as "Destination OR'd with Brush (pattern) OR'd with Source" and then blitted into the source. That is a fairly simple ROP3 code. Currently there is no suitable external library which could be exploited to make a DIBEngine in ReWind. One of the more promising libraries, Microwindows, has problems with different depths and ultimately has to be hooked into the underlying driver and hence does not solve the problem of removing the coercions. TRANSGAMING'S DIBENGINE ----------------------- TransGaming Technologies has been developing a DIBEngine in order to finally solve all the problems discussed above. The DIBEngine developed by TransGaming is partially complete, but more work is still needed for it to be fully functional. Current features include: o Drawing of lines o Partial drawing of ellipses o Drawing of polygons (several of the implementations, such as Polygon, Polyline, etc) o Filling of polygons (including patterns) o Pattern blitting o ROP2 and ROP3 engines Most of the support is there to complete the DIBEngine, for example the incomplete primitives can make use of the pattern blitting and so on. There is still a some functionality that has to be completed, and the current TODO list is as follows: o Implement outlined and filled shapes. o Implement curved shapes (Ellipse, Chord, Pie, Arc, etc). o Complete other drawing functionality (Round Rect, SetPixal etc). o Implement the different pens (Varying thickness, dotted, geometric, etc). o Line drawing needs to implement draw_last_point flag. o Brushes can only be 8x8 in Windows 95, we need to care about this. o Implement of clipping regions (Win32 has many types of clipping including rectangles, elliptic and more). o Implement text/fonts. o Take care of SetBrushOrgEx Currently the DIBEngine only supports a 16bit X Server and 16 bit drawing this means we need to: o Implement drawing for all possible depths (modify underlying pixel draw functions only). o Support Paletted modes. o Currently X11DRV_CreateBitmap only supports the current X depth. If a DIBSection is created at 32bits, and thus we try to use a 32bit brush, the whole thing will break. We either need to do depth conversions before calling X11DRV_CreateBitmap or do something else. Some things which need fixing up include: o Find depth masks for HBITMAPs o Properly implement BitBlt/PatBlt's and StertchBlt's. BitBlt takes the destination's DC functions, but this may not be safe if the source is not a DIBSection (see the information below on hooking into ReWind). o Optimzation. Currently the DIBEngine is not as fast as X for most drawing functions. Speedups can be done in the area of the ROP parser, pixel drawing, line drawing and filling. The code contains some comments of specific areas that need work. o DLL Seperation: Ideally the DIBEngine should be placed into its own DLL. This will allow it to be used for different graphics drivers, amongst other things. HOOKING INTO REWIND ------------------- For each GDI function that exists there is a driver-specific wrapper function that does some simply checking / optimizing / calculations before sending it onto the drivers specific rendering functions. For the X11DRV these exist in graphics/x11drv/graphics.c. This is where we divert calls to the DIBEngine when necessary. For speed optimizations (minimizing the number of coercions that take place) we put several conditions on which renderer to use. If the DIBSection is in gdimod (eg, Pixmap is most up-to-date) we use the drivers (eg, x11's) renderer; if the DIBSection is in appmod we use the DIBEngine. It should be noted that by doing this, the term 'gdimod' is now redundant because infact a DIBSection could be in appmod yet have been last modified by a GDI function.

1 0

Re: DIB engine
by Huw Davies 28 Sep '02

28 Sep '02

On Sat, Sep 28, 2002 at 01:11:57AM +0200, Ove Kaaven wrote: > Well, here is the DIB engine that a couple of people at TransGaming > (mostly David Hammerton, I think) did some work on a while ago, I finally > got around to review it and make sure it compiles against the current > ReWind (though perhaps it needs a few tweaks to compile against Wine). Well I haven't looked at it yet, but hey cool guys! Cheers! Huw.

1 0

minor typo in winemaker
by Bill Medland 28 Sep '02

28 Sep '02

1 0