Question on this debate:
Has AJ documented anywhere what the architectural issues are so they can be addressed? I have not seen this in the thread and was just wondering. If we have them documented then its a relatively easy task to address each of them. Yes it may be a hack but you would be surprised at how much of Windows is a hack internally.
Do we even have an architectural document or guidelines to reference?
Chris
On Fri, May 29, 2009 at 10:10 AM, chris ahrendt celticht32@yahoo.com wrote:
Question on this debate:
Has AJ documented anywhere what the architectural issues are so they can be addressed? I have not seen this in the thread and was just wondering. If we have them documented then its a relatively easy task to address each of them. Yes it may be a hack but you would be surprised at how much of Windows is a hack internally.
Do we even have an architectural document or guidelines to reference?
If you read the entire thread, you'll see that the DIB design is not a puzzle that can be carved out and dropped in. The DIB engine must be designed from scratch. Designing the DIB architecture is half of the work itself, since that involves planning a lot of the code/testing, etc.
He pointed out a few things he didn't like about Massimo's design, but not a full 'here's the spec, do this exactly'.
For more details, read the full thread and past discussions.
-- -Austin
2009/5/30 chris ahrendt celticht32@yahoo.com:
Question on this debate:
Has AJ documented anywhere what the architectural issues are so they can be addressed?
This did not need a new thread. You should have posted it on the existing one.
I have not seen this in the thread and was just wondering. If we have them documented then its a relatively easy task to address each of them. Yes it may be a hack but you would be surprised at how much of Windows is a hack internally.
You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks, hence AJ's reluctance to include the current DIB proposal in Wine (to make it "correct" later will require a lot of hacking, as Max has objected).
Do we even have an architectural document or guidelines to reference?
This was also raised on the existing thread. No. This is a problem. The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source.
This leads me to my second point.
2009/5/30Z Stephan Rose kermos@somrek.net:
My ears perked up when the two words DIB and spec were put together in the same sentence. One frustration I encountered when wanting to contribute to wine a little over two years ago was that nobody seemed to be able to say "Hey, this is what we are missing/need, here are the specs, go implement". Essentially, that's how I work and how I work well. Trying to fix random bugs in random applications in a codebase completely unfamiliar to me seemed to be rather futile so at that point in time I abandoned those efforts and just stuck to using wine. =P
So that said, I've got a decent amount of experiences dealing with graphics, including full 24/32-bit color on embedded devices. Considering the environment, performance has always been a priority as well. Plus, I also really like working with graphics related code. So from where I'm standing right now, this seems to be right in my neighbourhood.
So if anyone can drop a full spec into my lap which outlines everything I need to write and where (given I adhere to things as I should of course) I won't have any issues getting that accepted later on, I'd be more than willing to take on something like this.
Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32.
Ben Klein ha scritto:
You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks,
Well, well.... there are some, indeed. Of course, it's better not add new ones :-)
hence AJ's reluctance to include the current
DIB proposal in Wine (to make it "correct" later will require a lot of hacking, as Max has objected).
Again, my engine isn't a hack. Nor you'll need hacks to embed it on gdi32. Even more, some parts will be simplified because of direct access to internal gdi32 structures, which can't be done (without hacks....) in current implementation. The *only* semi-hack is the direct access of gdifont struct from inside winedib.... it could also be avoided, but with much useless code added. Useless because it will be so once embedded in gdi32.
Do we even have an architectural document or guidelines to reference?
This was also raised on the existing thread. No. This is a problem. The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source.
You got exactly the point :-) To be precise, the effort isn't so huge, but summed with the effort of maintaining all in sync with current tree the global effort would be great (and dumb, imho).
Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32.
There's not too much to adapt.... moving the engine inside gdi32 is (IMHO) not complicated at all. More a writing effort than a coding one. But, *before*, I guess winex11.drv (and any possible driver that does DIBs internally) should be patched stripping DIB handling *and* adding some stuffs for mixed transfers. Again, not an huge work, for somebody that knows well drivers internals. It could also be done later, if wished... but logically that would be the first step.
Ciao
Max
-
Austin English -
Ben Klein -
chris ahrendt -
Massimo Del Fedele