DIB engine
Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, [EMAIL PROTECTED]
Re: DIB engine
Hi, Before you re-invent the wheel - David (forgot his family name, sorry David) from Transgaming (if I'm not mistaken) has started to work on a DIB engine that uses SDL, so you might want to collaborate with him on his engine.. This reminds me a question: Is there a way that instead of using the DIB engine, to create an RDP events and show them in an application like rdesktop? Thanks, Hetz On Sunday 01 December 2002 22:52, Johan Gill wrote: Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, [EMAIL PROTECTED]
Re: DIB engine
Hi Hetz, Just a few clarifications. The TransGaming DIBengine doesn't use SDL, and it was written mostly by Jonathan Meunier with help from Gav, Peter and myself. Anyhow, I believe Johan Gill is aware that we have the dibengine, and is in fact probably refering to it (as I have had private correspondence with him) For those who don't follow this list all the time, more information can be found in these two threads: http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html and http://www.winehq.com/hypermail/wine-devel/2002/11/0849.html Cheers David On Mon, 2 Dec 2002 08:17, Hetz Ben Hamo wrote: Hi, Before you re-invent the wheel - David (forgot his family name, sorry David) from Transgaming (if I'm not mistaken) has started to work on a DIB engine that uses SDL, so you might want to collaborate with him on his engine.. This reminds me a question: Is there a way that instead of using the DIB engine, to create an RDP events and show them in an application like rdesktop? Thanks, Hetz On Sunday 01 December 2002 22:52, Johan Gill wrote: Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, [EMAIL PROTECTED]
Re: Re: DIB engine
I'll probably be taking a look at merging in the dib engine in the next few weeks as part of ongoing work to improve d3d support. If someone happens to start sooner just mail the list so we don't duplicate work. Chris From: Greg Turner [EMAIL PROTECTED] Date: 2002/11/13 Wed AM 08:58:54 EST To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: DIB engine Impolitely cc'ed to wine-devel w/o your permission... On Tuesday 12 November 2002 11:30 pm, [EMAIL PROTECTED] wrote: Just curious, in lieu of your excellent merging skills, [...] heh, what a silly claim to fame. But thanks for the compliment :) have you considered tackling the DIB engine from TransGaming? actually, I have. Maybe once I finish the current wave of work on rpcss (soon, I think) I will take a look at this. It might be a little more of a challenge for me since I don't know a thing about X11 coding... but then again I didn't know much about RPC until I started diving into it, and since I hear it's a bit of a challenge, the prospect of learning X11 coding appeals to me anyhow. Once again, it seems like a huge code drop waiting for someone to split it up. I looked through it briefly and it looked fairly straightforward. Maybe Huw Davies has some ideas about it? yup. The only thing that gives me pause is that the RPC stuff is far from finished and I would like to keep some forward momentum in that department as well... but who says I can't multitask? I'd certainly be glad to take a look at it. -- gmt War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself. -- John Stuart Mill
Re: DIB engine
On Wednesday 13 November 2002 10:10 am, [EMAIL PROTECTED] wrote: I'll probably be taking a look at merging in the dib engine in the next few weeks as part of ongoing work to improve d3d support. If someone happens to start sooner just mail the list so we don't duplicate work. 10-4. -- gmt
Re: DIB engine
[EMAIL PROTECTED] writes: I'll probably be taking a look at merging in the dib engine in the next few weeks as part of ongoing work to improve d3d support. If someone happens to start sooner just mail the list so we don't duplicate work. Note that simply merging the existing code is not enough, you'll need to fix the architecture. IMO it needs to be based on the DC driver interface, but this will also require some changes to that interface. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DIB engine
Hey Alexandre, Note that simply merging the existing code is not enough, you'll need to fix the architecture. IMO it needs to be based on the DC driver interface, but this will also require some changes to that interface. I presume with this you mean the way we hooked the dibengine into the x11drv? What we did (it's been a while, but if my memory serves) is modify x11drv's /graphics/x11drv/graphics.c so that the gdi calls were routed to the dibengine if the dibsection (or whatever) it's rendering to is in appmod. There is a very good reason for this: If we just always used the dibengine no matter what, we would sometimes 'lose' on the whole coerce thing - what if the dibsection (or whatever) is in gdimod, we'd then have to do a whole copy of it back to sync things up, which is just silly when we could use x11's renderer (the image is already over there)... Cheers David -- David Hammerton programmer TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED]
Re: DIB engine
David Hammerton [EMAIL PROTECTED] writes: If we just always used the dibengine no matter what, we would sometimes 'lose' on the whole coerce thing - what if the dibsection (or whatever) is in gdimod, we'd then have to do a whole copy of it back to sync things up, which is just silly when we could use x11's renderer (the image is already over there)... But if we always use the DIB engine there won't be any coerce stuff at all, everything will be done directly in the DIB and we won't use the X11 renderer. Then the only time you have to copy is when doing a BitBlt to the screen. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DIB engine
Alexandre Julliard wrote: David Hammerton [EMAIL PROTECTED] writes: If we just always used the dibengine no matter what, we would sometimes 'lose' on the whole coerce thing - what if the dibsection (or whatever) is in gdimod, we'd then have to do a whole copy of it back to sync things up, which is just silly when we could use x11's renderer (the image is already over there)... But if we always use the DIB engine there won't be any coerce stuff at all, everything will be done directly in the DIB and we won't use the X11 renderer. Then the only time you have to copy is when doing a BitBlt to the screen. The DIB engine is a long way from being finished, however. There are some major missing features - text rendering, for example. If the DIB engine is integrated in such a way that it completely replaces X rendering for DIBSections, it will work poorly for many applications, and would be less likely to get used and improved. With the current architecture, it can be improved on a completely incremental basis. -Gav -- Gavriel State, CEO CTO TransGaming Technologies Inc. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: DIB engine
On November 13, 2002 15:25, Alexandre Julliard wrote: But if we always use the DIB engine there won't be any coerce stuff at all, everything will be done directly in the DIB and we won't use the X11 renderer. Then the only time you have to copy is when doing a BitBlt to the screen. The non-fully operational DIB engine issue aside (I believe Gav covered that). I'm curious to know how you propose to hook the DIB engine in?.. I looked at several methods (changing the DC function table, for example) - none of them looked very appealing to us. The other issue to be considered, is it neceesarilly incorrect to call it from the driver? Ove tells me that in Windows drivers are responsible for calling Windows' DIB engine. This is because a) its easier for the driver to know whats going to be faster, b) when the driver doesn't implement something itself it just passes it off to the DIB engine. David -- David Hammerton programmer TransGaming Technologies Inc. http://www.transgaming.com/ [EMAIL PROTECTED]
Re: DIB engine
David Hammerton [EMAIL PROTECTED] writes: I'm curious to know how you propose to hook the DIB engine in?.. I looked at several methods (changing the DC function table, for example) - none of them looked very appealing to us. I don't know, the DC function table seems like the perfect tool for that, and much better than having to add checks in every single function of every driver. What do you see that's wrong with it? -- Alexandre Julliard [EMAIL PROTECTED]
Re: DIB engine
Gavriel State [EMAIL PROTECTED] writes: The DIB engine is a long way from being finished, however. There are some major missing features - text rendering, for example. If the DIB engine is integrated in such a way that it completely replaces X rendering for DIBSections, it will work poorly for many applications, and would be less likely to get used and improved. Of course the counter argument is that if it visibly breaks something it's more likely to make people care... With the current architecture, it can be improved on a completely incremental basis. True; OTOH it's also easier to pick the right architecture while there is little code written, than once it's being used all over the place inside the x11 driver. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DIB engine
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.
Re: DIB engine
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/ [EMAIL PROTECTED] 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
Re: DIB engine
On Sat, Mar 30, 2002 at 04:57:09PM -0800, Francois Gouget wrote: We make use of Shared Memory Pixmaps to reduce the copying (in WineX).. So we have app memory which stores the image in the mode requested by the app, this then gets copied into a SHMPixmap of the depth supported by X so X can do whatever it wants to (render to it or whatever) and it then gets copied back when needed, same method.. One of the big savers here is that the ShmPixmap means we dont have to be sending stuff between X server/client, saves alot of time.. As for X supporting multiple depths - I investigated this and talked to some of the X coders, its still not wonderfully supported.. ehm, it lacks alot of the most common modes - eg 8bit paletted - its not really worth it from what I can see.. The X developers suggested that if I wanted to go down this road to first write an X extension, ShmPixmaps were nicer and almost as fast... Maybe you would have been able to see this if AoE2 didn't crash on Gav ;-). Cheers David But, as far as I can remember, the other big problem comes from the 'exception handler' that is needed to detect direct write from the Windows program to the DIB (or maybe I am thinking about something completely else :-) ) to be sure that the X pixmap and the Windows DIB are always in sync one with the other. And that cannot be solved easily with X Pixmaps at all (maybe hacking around with XShmPixmaps). Yes this endless copying is a performance killer. But even if you are not concerned about performance there are issues as I mentioned above. I think Transgaming did some work on optimizing this to limit the number of copies this but I don't remember the details. Some of it is already in Wine, I don't know if they have more stuff in WineX / coming to Wine. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Demander si un ordinateur peut penser revient ? demander si un sous-marin peut nager. -- David Hammerton Programmer, TransGaming Technologies http://www.transgaming.com/
DIB engine
The DIB engine was discussed quite a lot at WineConf. I am now trying to summarize these discussions to update bug 421 - Implement a DIB engine. http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=421 Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers? This was discussed quite a bit at WineConf. Ideas that were floated around are: 1. Have X export the required API - XFree86 4 has all the needed code, for all bit depths and layouts we care about. We could try to have the X guys export this in the form of an API ala Xft. Wine could then link with this library to implement the DIB engine (or dlopen that library). * Is the needed API already available? * If not, are the XFree86 guys willing to export it? * Almost everyone is using XFree86, but what about people who don't (embedded devices, Wine on Solaris...). We need a fallback. * We won't have to maintain that code which is a good thing, although it is not supposed to change much once written. * Will we be able to do all that we need with that API? Probably yes since it can be expected to match the X API quite closely and we are abel to use the X API. 2. Copy the relevant X code into Wine - Since X has all the code and that code is under the X11 license we could copy it all into Wine. * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. 3. Copy the relevant code from MicroWindows/NanoGUI to Wine --- MicroWindows/NanoGUI also has code that could help us bootstrap our DIB engine. We probably don't want Wine to depend on these projects but we could copy their code into Wine. * Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. 4. Copy the relevant code from GGI to Wine -- GGI also has similar code. Again we probably don't want to introduce a dependency on GGI so the same questions apply: * Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Utilisateur (nom commun) : Mot utilisé par les informaticiens en lieu et place d'idiot.
Re: DIB engine
1. Have X export the required API - XFree86 4 has all the needed code, for all bit depths and layouts we care about. We could try to have the X guys export this in the form of an API ala Xft. Wine could then link with this library to implement the DIB engine (or dlopen that library). Well, when I look at the bug report, I see this : '* the X bitmap has to be in the format of the X display. So if X is running in 15bpp, a 32bpp DIB is converted to 15bpp, the operation is performed in 15bpp, and the bitmap is then converted back to 32bpp. Obviously this implies that each operation occurs a loss of color resolution (fortunately they should not accumulate).' This is, AFAIK, not a problem anymore on XFree 4 (at least on the drivers based on the 'fb' driver) as they support all Pixmap depth whatever the depth of the current screen. For example, on my 16bpp display, 'xdpyinfo' gives me this : number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 So it should support almost all 'usual' formats (except the funky non 555 / 565 formats or BGR ones that are pretty rare). As far as I can remember, my Solaris box at work does also support a lot of Pixmap formats even on a 32bpp screen. There may be problems with the palette for the 'depth 8' format though. But, as far as I can remember, the other big problem comes from the 'exception handler' that is needed to detect direct write from the Windows program to the DIB (or maybe I am thinking about something completely else :-) ) to be sure that the X pixmap and the Windows DIB are always in sync one with the other. And that cannot be solved easily with X Pixmaps at all (maybe hacking around with XShmPixmaps). Anyway, enough of my ramblings for tonight :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
RE: DIB engine
I don't expect my comments will add much to this discussion because of my lack of coding ablity but this something ReactOS is going to need also. Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers? I will help with documentation/testing on this if that is needed. 1. Have X export the required API This wont help ReactOS out but it seems to me this is the quick/easy way to do it for you guys. 2. Copy the relevant X code into Wine I'm kinda like this idea. If this is the road you guys chose we should be able to make use of the code also. 3. Copy the relevant code from MicroWindows/NanoGUI to Wine Microwindows is GPL/MPL so Wine most likely cannot use its code. Greg might relicense some of the code for you though. Seeing as how DIB support is in use or needed by a lot of projects, why not take the X11 code And make a independent project? One that is licensed under X11 that can then be used By Wine, WineX, ReactOS, Microwindows and anyone else that needs it. Ok I'll shut up now Steven _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
