wine-devel May 2009

wine-devel@winehq.org

128 participants
234 discussions

WIne DIB
by chris ahrendt 31 May '09

31 May '09

On 05/30/2009 12:59 PM, wine-devel-request(a)winehq.org wrote: > 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 > > Ok Max then document what you think the effort would be and what is needed to migrate your DIB engine into GDI32 Then We could send it to AJ for approval and go from there. This would be documenting the Delta which should allow AJ to go line item by line item and say yes or no to each or what needs to do. How long would that take you to do Max? Once that is done we would have a defined plan etc and going forward it would be documented. Chris

3 2

Announcing WineConf 2009
by Hans Leidekker 30 May '09

30 May '09

Dear Wine developers, You may recall that I volunteered to help host WineConf in the Netherlands in 2007 when, after a vote, an offer by Dan Kegel to host at Google's offices in Zurich won the bid. Last year WineConf went across the pond to Minnesota, so it seems natural that this year's WineConf will be hosted in the country with the highest number of Wine developers per capita ;-) At Twente University Campus to be precise, near the city of Enschede: http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=1047705954276368339… From November 6-8 (Friday to Sunday). I chose this place because of its good facilities and relatively low costs; we want to make the conference accessible for as many developers as possible. Directions, agenda, etc. will be made available on this page: http://wiki.winehq.org/WineConf Please e-mail me at wineconf(a)meelstraat.net if you intend to come, so we can make a better estimation of the number of attendees. See you there! -Hans

5 7

Re: d3d10: Improve parse_fx10.
by Dmitry Timoshkov 30 May '09

30 May '09

"Rico Schüller" <kgbricola(a)web.de> wrote: > - /* version info? */ > - skip_dword_unknown(&ptr, 2); > + /* Compiled target version (e.g. fx_4_0=0xfeff1001, fx_4_1=0xfeff1011). */ > + read_dword(&ptr, &e->version); > + TRACE("Target: %#x\n", e->version); 0xfeff/0xfffe is a unicode byte order mark, could it serve the same purpose here? -- Dmitry.

3 2

DIB engine
by chris ahrendt 30 May '09

30 May '09

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

4 3

Re: DIB engine
by Stephan Rose 30 May '09

30 May '09

>>As was said in the other thread, just designing it alone would take a >>few months work. AJ is really busy with other things, and a few months >>work is both a lot of money and a lot of wasted productivity. No one >>is stepping up to sponsor the work, so it's a bit hard for him to take >>that on. > >Who is asking AJ to do all of the work. Huw Davies and Max have worked out >what is needed to get this into Wine. All we need is guidance on what is >acceptable and how we should proceed. This seems to be a serious shortcoming >on AJs part. Without this, any further work would be futile and could end up >being very frustrating. I've seen this from Huw and it is starting to come >from Max. AJ needs to get some time together and write up what is and is not >acceptable as far as code style, fashion and what he expects out of the >development efforts for the DIB engine. Making a statement >after months of work is IHMO very unacceptable. > >Also, I don't see this as circular, but the 'snake' of getting AJ to accept >code into the codebase is. This is where I figured I'd wake up and chime in a bit. None of you all know me I suppose but I've been primarily just listening in on this list for the better part of two years now. :) 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. Thanks, Stephan

2 1

Re: Time to remove obsolete platforms HP, SGI, and DEC?
by James Mckenzie 30 May '09

30 May '09

> >> Why do we have versions on Mac OS X? How about we combine them all? > >It can make a big difference in the bug. The X.org version in OS X >(partially?) depends on what OS X version you have. Some bugs will >only show up in Tiger, because Leopard has them fixed on Apple's end. >(Someone correct me if I'm wrong here, this is based off of what I've >seen on wine-users). > Very much correct. MacOSX 10.5.7 with XQuartz 2.3.3 or higher correctly utilize all OpenGL features present in Wine. MacOSX 10.4.x or MacOSX 10.5.6 or MacOSX 10.5.7 without XQuartz 2.3.3 applied will not. Since I am running MacOSX 10.5.7 with XQuartz 2.3.3.2 applied, I do not know the status of backporting the fixes to the 10.4 (Tiger) baseline or even if it is possible. As far as OS/2 goes, it is still a viable operating system, but I think, for Wine purposes, it should be dropped as an available OS for bugzilla and for the AppDB. James McKenzie

2 1

Re: DIB engine
by chris ahrendt 29 May '09

29 May '09

On 05/29/2009 12:28 PM, James Mckenzie wrote: >> As was said in the other thread, just designing it alone would take a >> few months work. AJ is really busy with other things, and a few months >> work is both a lot of money and a lot of wasted productivity. No one >> is stepping up to sponsor the work, so it's a bit hard for him to take >> that on. >> > Who is asking AJ to do all of the work. Huw Davies and Max have worked out what is needed to get this into Wine. All we need is guidance on what is acceptable and how we should proceed. This seems to be a serious shortcoming on AJs part. Without this, any further work would be futile and could end up being very frustrating. I've seen this from Huw and it is starting to come from Max. AJ needs to get some time together and write up what is and is not acceptable as far as code style, fashion and what he expects out of the development efforts for the DIB engine. Making a statement > after months of work is IHMO very unacceptable. > > Also, I don't see this as circular, but the 'snake' of getting AJ to accept code into the codebase is. > > Very respectfully submitted, > > James McKenzie > > > > Agreed James, this is the exact point I am getting at I guess... what exactly is acceptable and what is not... It seems we have a working solution for DIB. I do not think that it would take that long for AJ to sit down and say here.. this is what I want or this is what is acceptable then its up to the development people to come back and say ok here is our solution and then rectify the delta's in between. If Huw and Max have a solution then what is the delta? Chris

1 0

Time to remove obsolete platforms HP, SGI, and DEC?
by Dan Kegel 29 May '09

29 May '09

The only use of these platforms was three mistaken bug reports that probably wanted PC. I don't see any reason to keep these old system types around any more. OK to remove? (Suggested in http://bugs.winehq.org/show_bug.cgi?id=13363 )

5 9

Re: DIB engine
by James Mckenzie 29 May '09

29 May '09

Luke: > >Heh, I wonder if someone should approach Autodesk and say, "Give us >sponsorship and we'll get Autocad running on Linux" they surely have >deep pockets :) > If Autodesk were interested in making AutoCad work with Linux, they would make a native version, not try to get it working with Wine. Sorry, but them's the facts. Now, if you were to speak up with your wallet and donate to the effort, that is a vastly different story. Sadly, we are on our own to get AutoCad fully working with Wine. I don't expect any assistance from AutoDesk nor any of the major Linux players. James McKenzie

2 1

Re: DIB engine
by James Mckenzie 29 May '09

29 May '09

>As was said in the other thread, just designing it alone would take a >few months work. AJ is really busy with other things, and a few months >work is both a lot of money and a lot of wasted productivity. No one >is stepping up to sponsor the work, so it's a bit hard for him to take >that on. Who is asking AJ to do all of the work. Huw Davies and Max have worked out what is needed to get this into Wine. All we need is guidance on what is acceptable and how we should proceed. This seems to be a serious shortcoming on AJs part. Without this, any further work would be futile and could end up being very frustrating. I've seen this from Huw and it is starting to come from Max. AJ needs to get some time together and write up what is and is not acceptable as far as code style, fashion and what he expects out of the development efforts for the DIB engine. Making a statement after months of work is IHMO very unacceptable. Also, I don't see this as circular, but the 'snake' of getting AJ to accept code into the codebase is. Very respectfully submitted, James McKenzie

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2009