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 gmturner007@ameritech.net Date: 2002/11/13 Wed AM 08:58:54 EST To: vinn@theshell.com CC: wine-devel@winehq.com Subject: Re: DIB engine
Impolitely cc'ed to wine-devel w/o your permission...
On Tuesday 12 November 2002 11:30 pm, vinn@theshell.com 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
On Wednesday 13 November 2002 10:10 am, chrismorgan@rcn.com 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.
chrismorgan@rcn.com 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.
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 david@transgaming.com 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 wrote:
David Hammerton david@transgaming.com 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 gav@transgaming.com 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.
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 david@transgaming.com 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 -
chrismorgan＠rcn.com -
David Hammerton -
Gavriel State -
Greg Turner