An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Any objections? I'm thinking of asking a summer intern to try this. - Dan
So what would be the overall of the project? I'm interested in participating in this Google SoC, so this project sound interesting to me for this SoC 2007. Regards, Ivan On 3/9/07, Dan Kegel <dank(a)kegel.com> wrote:
An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Any objections? I'm thinking of asking a summer intern to try this. - Dan
On Thu, Mar 08, 2007 at 10:50:30PM -0800, Dan Kegel wrote:
An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it.
Yes, absolutely.
Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Except that's based on top of Cairo, whereas ours should be based on gdi32. Huw. -- Huw Davies huw(a)codeweavers.com
On 3/9/07, Huw Davies <huw(a)codeweavers.com> wrote:
On Thu, Mar 08, 2007 at 10:50:30PM -0800, Dan Kegel wrote:
An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it.
Yes, absolutely.
Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Except that's based on top of Cairo, whereas ours should be based on gdi32.
But cairo has a win32 backend. So I think we can use mono-libgdiplus.
Huw. -- Huw Davies huw(a)codeweavers.com
"Ivan de Jesus Deras Tabora" <ideras(a)gmail.com> wrote:
Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Except that's based on top of Cairo, whereas ours should be based on gdi32.
But cairo has a win32 backend. So I think we can use mono-libgdiplus.
Considering that gdiplus has a very poor performance under Windows because it doesn't have a dedicated DDI (device driver interface), adding gdiplus that uses a completely different backend into Wine would have even more performance related problems. How is that possible to mention gdiplus at all, if even so basic functionality as a DIB engine still is not implemented? Besides, my personal opinion is that implementing gdiplus is out of scope of the Wine project, just like MFC and similar libraries. -- Dmitry.
On Fri, Mar 09, 2007 at 10:35:20AM -0500, Ivan de Jesus Deras Tabora wrote:
On 3/9/07, Huw Davies <huw(a)codeweavers.com> wrote:
On Thu, Mar 08, 2007 at 10:50:30PM -0800, Dan Kegel wrote:
An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it.
Yes, absolutely.
Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Except that's based on top of Cairo, whereas ours should be based on gdi32.
But cairo has a win32 backend. So I think we can use mono-libgdiplus.
Even if we wanted to do it that way, it wouldn't work; gdiplus exposes gdi32 handles, so we'd somehow have to get these through Cairo. Huw. -- Huw Davies huw(a)codeweavers.com
Huw wrote:
Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways.
Except that's based on top of Cairo, whereas ours should be based on gdi32.
But cairo has a win32 backend. So I think we can use mono-libgdiplus.
Even if we wanted to do it that way, it wouldn't work; gdiplus exposes gdi32 handles, so we'd somehow have to get these through Cairo.
Well, I heard libgdiplus already has a bundled version of Cairo, we could replace that with a win32-cairo, then hack it up to let the gdi32 handles shine through, maybe... (For those looking for a pointer to cairo-win32, see http://mces.blogspot.com/2007/02/cairo-and-winelib-adventures.html Maybe we could start by just getting it building?) Whether or not gdiplus is in scope for wine is really a function of whether it's practical to implement, and whether doing so would solve important problems for us. Maybe it would help to list the problems we have with using native gdiplus. I think it's just two: some apps don't bundle it, and it might be slow. The speed problem might be solvable by doing a DIB engine instead, as Dmitry implied. So Huw, you sounded like you thought doing our own gdiplus was a good idea. How strongly do you feel about it? Think I should have somebody try to tackle a DIB engine instead? - Dan - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Dan Kegel wrote:
So Huw, you sounded like you thought doing our own gdiplus was a good idea. How strongly do you feel about it? Think I should have somebody try to tackle a DIB engine instead?
So I was talking to Ulrich a few days ago and he was moaning bitterly that a gdiplus app was very slow because the native gdiplus draws lines one pixel at a time blitting into dibsections. Now while a dib engine would indeed help here, another approach would be to have our gdiplus draw lines in a more Wine friendly manner. Of course when apps stop shipping gdiplus then we're going to need our own version anyway, just like any other dll. We'd like to have something useful before this day comes too. It seems to me that gdiplus is a great project for an intern; it's scalable and not 'all or nothing' unlike the dib engine. Huw.
Huw Davies [mailto:huw(a)codeweavers.com] wrote:
It seems to me that gdiplus is a great project for an intern; it's scalable and not 'all or nothing' unlike the dib engine.
In looking at the DIB engine I feel that one of the biggest obstacles to get it done is integrating it in a way that it can be partially integrated piece by piece without requiring a huge amount of patches that needs to be applied more or less in one go in order to still have it all work. On the other hand I think that is the only way to get it in at all unless Alexandre himself is going to do it and if you do it that way I would think it is not really an all or nothing thing. You can start with addition of infrastructure in the display driver interface without really changing anything in the actual handling. Once the necessary support to the display driver interface is done the DIB engine could be implemented and integrated piece by piece such as first Put/GetPixel operations and then lines, and so on. This means that the X server synchronization would have to remain in the X11 driver until every function is implemented but it could reduce the requirement to synchronize every time as DIB engine support for a new operation is added, although some operations won't have a lot of effect for most applications. I'm still convinced that the best aproach to integrate a DIB engine is inside GDI and not in the display driver. Not so much because it is easier (it seems not to be) but because it is cleaner and in the long run will benefit other possible display drivers too, without having to be concerned in such a driver about DIB operations if one doesn't really want to. I think likely candidates to have speed effects are Get/PutPixel, LineTo, and the various BitBlt operations, with the last ones probably being also the most complex ones. More esoteric operations such as Arcs will eventually have to be implemented too somehow but wouldn't be the most important ones to start with. Rolf Kalbermatter
participants (5)
-
Dan Kegel -
Dmitry Timoshkov -
Huw Davies -
Ivan de Jesus Deras Tabora -
Rolf Kalbermatter