I recently had a chat with Dan Kegel about the way to contribute and start hacking on a DIB engine. I grabbed Huw Davies and Jesse Allen's repositories and started looking at them. As it'll be an hard (and long) work, I'd like to know some opinions on how to proceed and propose an idea on how to have it introduced in mainstream without breaking stuff. The idea is, for now, JUST an idea and I still don't know if it'll be possible, but I guess yes. So, I was thinking on : 1) Try to join best stuffs of both repos of Huw and Jesse. 2) Add the environment variable DIBENGINE which could have 3 different values (or be missing) : missing DIBENGINE env var or DIBENGINE=NONE New dib engine will not be used, back to X11DRV DIBENGINE=FORWARD Unimplemented stuffs forwarded to X11, the rest using new dib engine code DIBENGINE=FULL use just dib engine code and shows FIXMEs for unimplemented stuffs The first would allow to insert dib engine in main stream without breaking anything, the last would allow to see what's more important to implement. The middle one (FORWARD) would allow to check if something breaks during the transition, and use the developed parts. 3) Stop and wait till it's put on mainstream, so more people could contribute. The doubt is if it'll be possible the mixed approach, forwarding unimplemented stuffs to X11, but I think so. Is it an acceptable way to proceed ? Ciao Max
В сообщении от Wednesday 12 November 2008 14:00:38 Massimo Del Fedele написал(а):
I recently had a chat with Dan Kegel about the way to contribute and start hacking on a DIB engine. I grabbed Huw Davies and Jesse Allen's repositories and started looking at them. As it'll be an hard (and long) work, I'd like to know some opinions on how to proceed and propose an idea on how to have it introduced in mainstream without breaking stuff. The idea is, for now, JUST an idea and I still don't know if it'll be possible, but I guess yes. So, I was thinking on :
1) Try to join best stuffs of both repos of Huw and Jesse.
2) Add the environment variable DIBENGINE which could have 3 different values (or be missing) :
missing DIBENGINE env var or DIBENGINE=NONE New dib engine will not be used, back to X11DRV
DIBENGINE=FORWARD Unimplemented stuffs forwarded to X11, the rest using new dib engine code
DIBENGINE=FULL use just dib engine code and shows FIXMEs for unimplemented stuffs
The first would allow to insert dib engine in main stream without breaking anything, the last would allow to see what's more important to implement. The middle one (FORWARD) would allow to check if something breaks during the transition, and use the developed parts.
3) Stop and wait till it's put on mainstream, so more people could contribute.
The doubt is if it'll be possible the mixed approach, forwarding unimplemented stuffs to X11, but I think so.
Is it an acceptable way to proceed ?
Ciao
Max
I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed: On 9/29/08, Sergey Novosyolov <chi(a)etersoft.ru> wrote:
The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers)
why can't we release DIB-Engine as own driver? GDI32 functions are main and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC)
Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format) > (The Driver should do Everything. When the driver call the GRE, > the DDB is converted to a DIB, GDI renders into the DIB and then > the DIB is converted back to a DDB) > => like our winex11.drv and wineps.drv
2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without converting) => Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments)
3: DIB (GDI renders everything) => The current Code is using a X11-DDB (Driver Managed) with converting issues.
So the conception of new strusture of DIB ENgine inside GDI is needed
Sergey Novosyolov ha scritto:
I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed: On 9/29/08, Sergey Novosyolov <chi(a)etersoft.ru> wrote:
The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers)
why can't we release DIB-Engine as own driver? GDI32 functions are main and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC)
Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format) (The Driver should do Everything. When the driver call the GRE, the DDB is converted to a DIB, GDI renders into the DIB and then the DIB is converted back to a DDB) => like our winex11.drv and wineps.drv
2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without converting) => Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments)
3: DIB (GDI renders everything) => The current Code is using a X11-DDB (Driver Managed) with converting issues.
So the conception of new strusture of DIB ENgine inside GDI is needed
The question is if we should support native drivers or not, other than winex11 or wineps. For winex11, we're using native rendering functions, for wineps we're just translating GRE calls to ps code directly, no need to convert forth and back. Other stuff would be raw printing, for example, using native drivers.... but are they really needed ? AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB, in order to be able to use X11 rendering functions, so the point 3. I don't understand your point 1; why convert DDB to DIB ? Driver should render directly into DDB. GDI calls can be directed to native ones. I see it this way (but I could be wrong) : 1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats. 2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything. 3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed. So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format. Max
Sergey Novosyolov ha scritto:
I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB
inside
GDI32 as Detlef Riekenberg proposed: On 9/29/08, Sergey Novosyolov <chi(a)etersoft.ru> wrote:
The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers)
why can't we release DIB-Engine as own driver? GDI32 functions are main and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC)
Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format) (The Driver should do Everything. When the driver call the GRE, the DDB is converted to a DIB, GDI renders into the DIB and then the DIB is converted back to a DDB) => like our winex11.drv and wineps.drv
2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without converting) => Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments)
3: DIB (GDI renders everything) => The current Code is using a X11-DDB (Driver Managed) with converting issues.
So the conception of new strusture of DIB ENgine inside GDI is needed
The question is if we should support native drivers or not, other than winex11 or wineps. For winex11, we're using native rendering functions, for wineps we're just translating GRE calls to ps code directly, no need to convert forth and back. Other stuff would be raw printing, for example, using native drivers.... but are they really needed ?
AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB, in order to be able to use X11 rendering functions, so the point 3. I don't understand your point 1; why convert DDB to DIB ? Driver should render directly into DDB. GDI calls can be directed to native ones.
I see it this way (but I could be wrong) :
1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats.
2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything.
3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed.
So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format.
Max
Under the hood Windows uses Eng* functions in the win2k/winxp driver model (perhaps even Vista, don't know). It is a different architecture than what Wine uses we are close to a win3.1 design. The use of the real win32 functions would offer the possibility of using native printer drivers again (not sure if this is something we really want). Doing stuff the microsoft way might have advantages for properly integrating ddraw and other things. On the other hand it could be a lot of work to get right. Here's my view on DirectDraw / D3D and the DIB engine. There are two cases. First of all you have plain 'software rendering' in which we do 2d ddraw using GDI and DIB. The use of a DIB engine would save us some roundtrips to X and make color conversion more efficient. Depending on the situation it could boost performance quite a bit. Second ddraw/d3d apps can use GetDC / ReleaseDC in order to get a HDC which they can use to draw to the ddraw surface. In case of D3D or 'hw accelerated' ddraw (DirectDrawRenderer=opengl) we need to read the image back from the videocard. Then the app works on it using GDI calls which at this point require evil color conversion and roundtrips to X. In the end the image is returned to wined3d and it is uploaded to the card. Various games use this method to draw text. Stefan's idea was to write a opengl dib engine for this. My own idea which matches a bit what Windows does is to use GLX_EXT_texture_from_pixmap which all drivers are starting to support. The idea would be that WineD3D downloads the image from the videocard. The dib engine would render in software to the dib and then GLX_EXT_texture_from_pixmap is used to reupload the corresponding pixmap to the videocard (the pixmap needs to be in the same depth as X). This could be done in different ways. I can imagine that a game uses 8bit (but using opengl we render it at 24bit) and that the dib engine just keeps working at 24bit (it would need to convert all 8bit operations to 24bit), to prevent a lot of depth conversion. Windows also has functionality to improve ddraw and gdi interaction. It works in about the same way. Going this way could make ddraw-gl finally hw accelerated in all areas. Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Roderick Colenbrander ha scritto:
Under the hood Windows uses Eng* functions in the win2k/winxp driver model (perhaps even Vista, don't know). It is a different architecture than what Wine uses we are close to a win3.1 design. The use of the real win32 functions would offer the possibility of using native printer drivers again (not sure if this is something we really want). Doing stuff the microsoft way might have advantages for properly integrating ddraw and other things. On the other hand it could be a lot of work to get right.
I'm afraid too... I think we've got do decide if do it on the quick side or on the "right" side. IMHO I'd choose the first one for the moment....
Here's my view on DirectDraw / D3D and the DIB engine. There are two cases. First of all you have plain 'software rendering' in which we do 2d ddraw using GDI and DIB. The use of a DIB engine would save us some roundtrips to X and make color conversion more efficient. Depending on the situation it could boost performance quite a bit.
That's what I'd like to solve first, but it's maybe too deeply tied to the other stuffs... still don't know. I've seen that in Autocad all rendering (in 2d mode) is done by autocad itself, besides TTF fonts. When there are TTF fonts inside drawing, the most time is spent in dib_coerce stuff, so translating DIB to X11 and back, in order to use X11 font rendering engine. The speed difference between TTF and non-TTF is something like 100:1 or worse. Switching to 3d mode, the font rendering is done (ugly) by autocad itself, so the things speeds up a lot (but some half speed than in 2d mode, indeed). Fonts are just outlined, line styles are not applied, etc, so it's not a viable workaround. What I'd like to know... It would make sense (I mean, could it enter wine repo) to extend Huw Davies/Jesse Allen's approach of implementing the engine ? I'd like to try it, but I'd not like to spend some weeks/months coding using the wrong approach :-) Also I'd like to see in wine a partial DIB engine, as I explained at post starting. Would it be possible, or shall I stop it by now ? Max
В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del Fedele написал(а):
Sergey Novosyolov ha scritto:
I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed:
On 9/29/08, Sergey Novosyolov <chi(a)etersoft.ru> wrote:
The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers)
why can't we release DIB-Engine as own driver? GDI32 functions are main and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC)
Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format)
(The Driver should do Everything. When the driver call the GRE, the DDB is converted to a DIB, GDI renders into the DIB and then the DIB is converted back to a DDB)
=> like our winex11.drv and wineps.drv
2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without converting) => Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments)
3: DIB (GDI renders everything) => The current Code is using a X11-DDB (Driver Managed) with converting issues.
So the conception of new strusture of DIB ENgine inside GDI is needed
The question is if we should support native drivers or not, other than winex11 or wineps. For winex11, we're using native rendering functions, for wineps we're just translating GRE calls to ps code directly, no need to convert forth and back. Other stuff would be raw printing, for example, using native drivers.... but are they really needed ?
AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB, in order to be able to use X11 rendering functions, so the point 3. I don't understand your point 1; why convert DDB to DIB ? Driver should render directly into DDB. GDI calls can be directed to native ones.
I see it this way (but I could be wrong) :
1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats.
As i see if we operate with Display DC we no need to convert and GDI32 calls X11DRV functions directly. If we operate with memoryDC GDI calls DIB functions and then uses BitBlt if needed to reflect memoryDC operations on teh display
2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything.
what do you mean "native format"? is it connected with GDI calls?
3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed.
I agree
So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format.
DIB is Device Independent Bitmap so DIB functions would be include those functions which implemented the same independ of device
Max
В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del Fedele написал(а):
Sergey Novosyolov ha scritto:
I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed:
On 9/29/08, Sergey Novosyolov <chi(a)etersoft.ru> wrote:
The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers)
why can't we release DIB-Engine as own driver? GDI32 functions are main and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC)
Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format)
(The Driver should do Everything. When the driver call the GRE, the DDB is converted to a DIB, GDI renders into the DIB and then the DIB is converted back to a DDB)
=> like our winex11.drv and wineps.drv
2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without converting) => Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments)
3: DIB (GDI renders everything) => The current Code is using a X11-DDB (Driver Managed) with converting issues.
So the conception of new strusture of DIB ENgine inside GDI is needed
The question is if we should support native drivers or not, other than winex11 or wineps. For winex11, we're using native rendering functions, for wineps we're just translating GRE calls to ps code directly, no need to convert forth and back. Other stuff would be raw printing, for example, using native drivers.... but are they really needed ?
AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB, in order to be able to use X11 rendering functions, so the point 3. I don't understand your point 1; why convert DDB to DIB ? Driver should render directly into DDB. GDI calls can be directed to native ones.
I see it this way (but I could be wrong) :
1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats.
As i see if we operate with Display DC we no need to convert and GDI32 calls X11DRV functions directly.
If we operate with memoryDC GDI calls DIB functions and then uses BitBlt if needed to reflect memoryDC operations on teh display
2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything.
what do you mean "native format"? is it connected with GDI calls?
3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed.
I agree
So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format.
DIB is Device Independent Bitmap so DIB functions would be include those functions which implemented the same independ of device
Max
From reading all your mails I get the impression that Etersoft is also doing some work on the DIB engine. What work has Etersoft done on this area? It might be wise to post the code somewhere for review before the wrong direction is taken again and it might prevent code duplication.
Roderick -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
В сообщении от Friday 14 November 2008 12:43:48 Roderick Colenbrander написал(а):
В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del Fedele
написал(а):
Sergey Novosyolov ha scritto:
I've already started working on it about 3 months ago and released
some
functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed:
On 9/29/08, Sergey Novosyolov <chi(a)etersoft.ru> wrote:
The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror
/
remote display drivers)
why can't we release DIB-Engine as own driver? GDI32 functions are
main
and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC)
Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format)
(The Driver should do Everything. When the driver call the GRE, the DDB is converted to a DIB, GDI renders into the DIB and then the DIB is converted back to a DDB)
=> like our winex11.drv and wineps.drv
2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without
converting)
=> Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments)
3: DIB (GDI renders everything) => The current Code is using a X11-DDB (Driver Managed) with converting issues.
So the conception of new strusture of DIB ENgine inside GDI is needed
The question is if we should support native drivers or not, other than winex11 or wineps. For winex11, we're using native rendering functions, for wineps we're just translating GRE calls to ps code directly, no need to convert forth and back. Other stuff would be raw printing, for example, using native drivers.... but are they really needed ?
AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB, in order to be able to use X11 rendering functions, so the point 3. I don't understand your point 1; why convert DDB to DIB ? Driver should render directly into DDB. GDI calls can be directed to native ones.
I see it this way (but I could be wrong) :
1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats.
As i see if we operate with Display DC we no need to convert and GDI32 calls X11DRV functions directly.
If we operate with memoryDC GDI calls DIB functions and then uses BitBlt if needed to reflect memoryDC operations on teh display
2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything.
what do you mean "native format"? is it connected with GDI calls?
3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed.
I agree
So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format.
DIB is Device Independent Bitmap so DIB functions would be include those functions which implemented the same independ of device
Max
From reading all your mails I get the impression that Etersoft is also doing some work on the DIB engine. What work has Etersoft done on this area? It might be wise to post the code somewhere for review before the wrong direction is taken again and it might prevent code duplication.
Roderick
We have received Huw Davies and Jesse Allen gits with their versions of DIB and continued working on it. But we're planning to change DIB Engine structure in these cases: 1. Releasing DIB Engine functions inside GDI. 2. Releasing interactioin DIB Engine with other drivers (such as X11, PS etc.) Today we've developed some DIB functions iwithout cnaging DIB driver structure. The main structure of DIB is just an idea and it was not changed yet.
Vitaliy Margolen ha scritto:
Massimo Del Fedele wrote:
2) Add the environment variable DIBENGINE which could have 3 different values (or be missing) :
If you want to go this way, you should use registry instead.
Vitaliy
Ok, it was meant as a temporary stuff, so I thought to an environment variable, but the final result would be the same, so it's not so important where is it. Max
Well, I managed to introduce Jesse Allen's dib engine in current wine tree, and it worked. It has many stubbed functions, but I could load and run Autocad with it, which IMHO is a good result. Autocad misses many toolbar's icons but, about the problem of very slow TT fonts, the performance increased noticeably; pannin a drawing with TT fonts wend from a frame each 2-5 seconds to a frame each 0.2 seconds about. Now, before trying to extend it, I'd like to know if, introducing a way to enable/disable it by environ var OR registry entry it could enter current devel tree. Ciao Max
I put a testing patch (which introduces Jesse Allen's dib engine in current tree) on bugzilla - Bug 421 page. The engine was tested on autocad (many display problems, but noticeable speedup) and with Excel (quickly, works, display problems in dialogs). The patch is just for testing purposes and to get some advice on how to proceed. http://bugs.winehq.org/show_bug.cgi?id=421 Ciao Max
participants (4)
-
Massimo Del Fedele -
Roderick Colenbrander -
Sergey Novosyolov -
Vitaliy Margolen