Re: Work on WineQuartz for MacOSX
On 18.05.2010, at 17:53, Roderick Colenbrander wrote: > On Tue, May 18, 2010 at 3:12 PM, Mike Kronenberg > wrote: >> On 17.05.2010, at 07:52, Charles Davis wrote: >> >>> On 5/16/10 9:04 PM, James Mckenzie wrote: Roderick Colenbrander wrote: > On Sun, May 16, 2010 at 6:02 PM, C.W. Betts > wrote: >> On May 16, 2010, at 9:31 AM, James Mckenzie wrote: >>> All: >>> >>> There was or is a quite lengthy thread on this project. >>> >>> What is the status of work? Any progress on Emmanuel's work from 2008? >>> >>> Thank you. >>> >>> James McKenzie >>> >> If memory serves, the main reason why there hasn't been any work done is >> because of the >> dependency of Objective-C, which the project administrator has said "no" >> to. >> > The fact that Cocoa is objective C is one of the issues (Charles Davis > made some C wrapper I think). The most problematic thing is that it > really need is a DIB engine. The Cocoa graphics APIs are similar to > Cairo / XRender / Direct2D and other modern APIs. These APIs are great > for vector drawing, alpha blending and other fancy operations but they > are not low-level 2D APIs. For instance they lack most classic > (bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this > way as well) has to be performed in software by a DIB engine. > > Roderick > Charles Davis did not 'make a c wrapper', Apple did. >>> Actually, he was referring to my tool for autogenerating C wrappers. I >>> haven't been working on it much, but I'll have it ready for you guys soon. However you are more correct in that we need a fully functional DIB engine in order to fully move the Apple interface from X11 to Aqua. >>> I agree. We need a DIB engine. Quartz by itself doesn't support >>> low-level raster operations (it's a vector engine). >> I did several implementations for the QEMU video output under OS X. >> The main grieve was Apple depreciating the QuickDraw API in 10.4 and >> removing it with 64bit. With this public direct buffer access gone, we did a >> quartz and a OpenGL implementation later. In the end, the OpenGL >> implementation won, as it was more portable, flexible and scaling comes for >> free (Fullscreen support). >> Basically one does the pixel manipulation in a buffer and loads that buffer >> as a texture at a fixed refresh rate (25/30/60hz?) if necessary. With Apples >> Client Storage and Texture Ranges [1], it proved to be the fastest pixel >> manipulation method and was very close to QD. >> Having a OpenGL based dib engine would work great with other OpenGL parts of >> wine (directx comes to mind) and it's open for porting. >> >> The OpenGL Code is still there, but I did not yet look at the current dib >> engine, yet. Any sparring partner? >> Mike >> >> [1] >> http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/opengl_texturedata.html >> >> >> > > The DIB engine has to be implemented in software. Important parts of > the DDB engine can be implemented using OpenGL. Parts which can be > implemented are things like BitBlt SRCCOPY, ColorFill, alpha blending > and some others it is similar to what Win7 accelerates and what APIs > like Cairo, XRender and others offer. > > Writing a DIB engine is not a trivial job and Alexandre has also said > a couple of times (for instance at WineConf) that not much people are > capable of it because it encompasses so much. I think only he and Huw > are capable at this point. No doubt on that one. And I'm not going to burn my fingers on the DIB engine itself. I'm merely talking about the backend for the actual output of a flat pixel-buffer on which the DIB engine's software part would work, which is trivial ;). So it's more a hint to implement a DIB engine to use a neutral buffer, so it could be used by different means of output. > Though in the Win7 design (if we would go > for that) the DIB engine is less complex as even most DDB operations > (except for the few common ones I mentioned) are done in software. > > Roderick smime.p7s Description: S/MIME cryptographic signature
Re: Work on WineQuartz for MacOSX
On Tue, May 18, 2010 at 3:12 PM, Mike Kronenberg wrote: > On 17.05.2010, at 07:52, Charles Davis wrote: > >> On 5/16/10 9:04 PM, James Mckenzie wrote: >>> Roderick Colenbrander wrote: On Sun, May 16, 2010 at 6:02 PM, C.W. Betts wrote: > On May 16, 2010, at 9:31 AM, James Mckenzie wrote: >> All: >> >> There was or is a quite lengthy thread on this project. >> >> What is the status of work? Any progress on Emmanuel's work from 2008? >> >> Thank you. >> >> James McKenzie >> > If memory serves, the main reason why there hasn't been any work done is > because of the > dependency of Objective-C, which the project administrator has said "no" > to. > The fact that Cocoa is objective C is one of the issues (Charles Davis made some C wrapper I think). The most problematic thing is that it really need is a DIB engine. The Cocoa graphics APIs are similar to Cairo / XRender / Direct2D and other modern APIs. These APIs are great for vector drawing, alpha blending and other fancy operations but they are not low-level 2D APIs. For instance they lack most classic (bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this way as well) has to be performed in software by a DIB engine. Roderick >>> Charles Davis did not 'make a c wrapper', Apple did. >> Actually, he was referring to my tool for autogenerating C wrappers. I >> haven't been working on it much, but I'll have it ready for you guys soon. >>> However you are more correct in that we need a fully functional DIB engine >>> in order to fully move the Apple interface from X11 to Aqua. >> I agree. We need a DIB engine. Quartz by itself doesn't support >> low-level raster operations (it's a vector engine). > I did several implementations for the QEMU video output under OS X. > The main grieve was Apple depreciating the QuickDraw API in 10.4 and removing > it with 64bit. With this public direct buffer access gone, we did a quartz > and a OpenGL implementation later. In the end, the OpenGL implementation won, > as it was more portable, flexible and scaling comes for free (Fullscreen > support). > Basically one does the pixel manipulation in a buffer and loads that buffer > as a texture at a fixed refresh rate (25/30/60hz?) if necessary. With Apples > Client Storage and Texture Ranges [1], it proved to be the fastest pixel > manipulation method and was very close to QD. > Having a OpenGL based dib engine would work great with other OpenGL parts of > wine (directx comes to mind) and it's open for porting. > > The OpenGL Code is still there, but I did not yet look at the current dib > engine, yet. Any sparring partner? > Mike > > [1] > http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/opengl_texturedata.html > > > The DIB engine has to be implemented in software. Important parts of the DDB engine can be implemented using OpenGL. Parts which can be implemented are things like BitBlt SRCCOPY, ColorFill, alpha blending and some others it is similar to what Win7 accelerates and what APIs like Cairo, XRender and others offer. Writing a DIB engine is not a trivial job and Alexandre has also said a couple of times (for instance at WineConf) that not much people are capable of it because it encompasses so much. I think only he and Huw are capable at this point. Though in the Win7 design (if we would go for that) the DIB engine is less complex as even most DDB operations (except for the few common ones I mentioned) are done in software. Roderick
Re: Work on WineQuartz for MacOSX
On 17.05.2010, at 07:52, Charles Davis wrote: > On 5/16/10 9:04 PM, James Mckenzie wrote: >> Roderick Colenbrander wrote: >>> On Sun, May 16, 2010 at 6:02 PM, C.W. Betts wrote: On May 16, 2010, at 9:31 AM, James Mckenzie wrote: > All: > > There was or is a quite lengthy thread on this project. > > What is the status of work? Any progress on Emmanuel's work from 2008? > > Thank you. > > James McKenzie > If memory serves, the main reason why there hasn't been any work done is because of the dependency of Objective-C, which the project administrator has said "no" to. >>> The fact that Cocoa is objective C is one of the issues (Charles Davis >>> made some C wrapper I think). The most problematic thing is that it >>> really need is a DIB engine. The Cocoa graphics APIs are similar to >>> Cairo / XRender / Direct2D and other modern APIs. These APIs are great >>> for vector drawing, alpha blending and other fancy operations but they >>> are not low-level 2D APIs. For instance they lack most classic >>> (bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this >>> way as well) has to be performed in software by a DIB engine. >>> >>> Roderick >>> >> Charles Davis did not 'make a c wrapper', Apple did. > Actually, he was referring to my tool for autogenerating C wrappers. I > haven't been working on it much, but I'll have it ready for you guys soon. >> However you are more correct in that we need a fully functional DIB engine >> in order to fully move the Apple interface from X11 to Aqua. > I agree. We need a DIB engine. Quartz by itself doesn't support > low-level raster operations (it's a vector engine). I did several implementations for the QEMU video output under OS X. The main grieve was Apple depreciating the QuickDraw API in 10.4 and removing it with 64bit. With this public direct buffer access gone, we did a quartz and a OpenGL implementation later. In the end, the OpenGL implementation won, as it was more portable, flexible and scaling comes for free (Fullscreen support). Basically one does the pixel manipulation in a buffer and loads that buffer as a texture at a fixed refresh rate (25/30/60hz?) if necessary. With Apples Client Storage and Texture Ranges [1], it proved to be the fastest pixel manipulation method and was very close to QD. Having a OpenGL based dib engine would work great with other OpenGL parts of wine (directx comes to mind) and it's open for porting. The OpenGL Code is still there, but I did not yet look at the current dib engine, yet. Any sparring partner? Mike [1] http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/opengl_texturedata.html smime.p7s Description: S/MIME cryptographic signature
Re: Work on WineQuartz for MacOSX
On 5/16/10 9:04 PM, James Mckenzie wrote: > Roderick Colenbrander wrote: >> On Sun, May 16, 2010 at 6:02 PM, C.W. Betts wrote: >>> On May 16, 2010, at 9:31 AM, James Mckenzie wrote: All: There was or is a quite lengthy thread on this project. What is the status of work? Any progress on Emmanuel's work from 2008? Thank you. James McKenzie >>> If memory serves, the main reason why there hasn't been any work done is >>> because of the >>> dependency of Objective-C, which the project administrator has said "no" to. >>> >> The fact that Cocoa is objective C is one of the issues (Charles Davis >> made some C wrapper I think). The most problematic thing is that it >> really need is a DIB engine. The Cocoa graphics APIs are similar to >> Cairo / XRender / Direct2D and other modern APIs. These APIs are great >> for vector drawing, alpha blending and other fancy operations but they >> are not low-level 2D APIs. For instance they lack most classic >> (bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this >> way as well) has to be performed in software by a DIB engine. >> >> Roderick >> > Charles Davis did not 'make a c wrapper', Apple did. Actually, he was referring to my tool for autogenerating C wrappers. I haven't been working on it much, but I'll have it ready for you guys soon. > However you are more correct in that we need a fully functional DIB engine > in order to fully move the Apple interface from X11 to Aqua. I agree. We need a DIB engine. Quartz by itself doesn't support low-level raster operations (it's a vector engine). > I was inquiring if both of these actions have occurred. Not really. Not as far as I know. I have a Quartz Driver in my tree, but it's nowhere near finished. I'm now thinking about merging mine and Emmanuel's work. Maybe if I put the two half-finished drivers together, we'll have a better working driver (without DIB support, but that needs either the DIB engine or some other way to accelerate DIB drawing). > Max was working diligently on a DIB engine until AJ basically shot his work > full of holes and he left. Someone needs to pick up his work--or at least, the job of writing a DIB engine. Personally, I would write one from scratch instead of trying to integrate X11's software drawing engine. It's been said that the X11 server code isn't known for its neatness... But that's just me. > > Again, what is the status of updating/upgrading Emmanuel's work? Has it been > left for dead or is someone working in the background on it? As soon as I'm finished with my C wrapper generator, I'll take a look at Emmanuel's Quartz Driver. Chip
Re: Work on WineQuartz for MacOSX
Roderick Colenbrander wrote: >On Sun, May 16, 2010 at 6:02 PM, C.W. Betts wrote: >> On May 16, 2010, at 9:31 AM, James Mckenzie wrote: >>> All: >>> >>> There was or is a quite lengthy thread on this project. >>> >>> What is the status of work? Any progress on Emmanuel's work from 2008? >>> >>> Thank you. >>> >>> James McKenzie >>> >> If memory serves, the main reason why there hasn't been any work done is >> because of the >> dependency of Objective-C, which the project administrator has said "no" to. >> >The fact that Cocoa is objective C is one of the issues (Charles Davis >made some C wrapper I think). The most problematic thing is that it >really need is a DIB engine. The Cocoa graphics APIs are similar to >Cairo / XRender / Direct2D and other modern APIs. These APIs are great >for vector drawing, alpha blending and other fancy operations but they >are not low-level 2D APIs. For instance they lack most classic >(bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this >way as well) has to be performed in software by a DIB engine. > >Roderick > Charles Davis did not 'make a c wrapper', Apple did. However you are more correct in that we need a fully functional DIB engine in order to fully move the Apple interface from X11 to Aqua. I was inquiring if both of these actions have occurred. Max was working diligently on a DIB engine until AJ basically shot his work full of holes and he left. Again, what is the status of updating/upgrading Emmanuel's work? Has it been left for dead or is someone working in the background on it? I would like to pick it up and start looking at it again and seeing if the Obj-C code could be converted to plain 'c' or if we have to bring up a sidebar version of Wine that will be Aqua complaint. Having been through this with the OpenOffice.org and NeoOffice.org projects, this is a political area I really don't want to visit, but if it has to be that way, then it will head off in that direction. James McKenzie
Re: Work on WineQuartz for MacOSX
The fact that Cocoa is objective C is one of the issues (Charles Davis made some C wrapper I think). The most problematic thing is that it really need is a DIB engine. The Cocoa graphics APIs are similar to Cairo / XRender / Direct2D and other modern APIs. These APIs are great for vector drawing, alpha blending and other fancy operations but they are not low-level 2D APIs. For instance they lack most classic (bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this way as well) has to be performed in software by a DIB engine. Roderick On Sun, May 16, 2010 at 6:02 PM, C.W. Betts wrote: > If memory serves, the main reason why there hasn't been any work done is > because of the dependency of Objective-C, which the project administrator has > said "no" to. > On May 16, 2010, at 9:31 AM, James Mckenzie wrote: > >> All: >> >> There was or is a quite lengthy thread on this project. >> >> What is the status of work? Any progress on Emmanuel's work from 2008? >> >> Thank you. >> >> James McKenzie >> >> >> >> >> > > > >
Re: Work on WineQuartz for MacOSX
On May 16, 2010, at 12:29 PM, James Mckenzie wrote: > C.W. > > The page referred to by this message no longer exists > > Time for an update. Include the period at the end. It works then. I was able to get the code and compile it fine under 32-bit mode. Apparently there has been a few changes in 64-bit mode that doesn't make it work quite as well. > > James McKenzie > > > > -Original Message- >> From: "C.W. Betts" >> Sent: May 16, 2010 10:06 AM >> To: wine-devel@winehq.org >> Subject: Fwd: Work on WineQuartz for MacOSX >> >> >> >> Begin forwarded message: >> >>> From: Erich Hoover >>> Date: May 16, 2010 10:10:29 AM MDT >>> To: "C.W. Betts" >>> Subject: Re: Work on WineQuartz for MacOSX >>> >>> On Sun, May 16, 2010 at 10:02 AM, C.W. Betts >>> wrote: >>> If memory serves, the main reason why there hasn't been any work done is >>> because of the dependency of Objective-C, which the project administrator >>> has said "no" to. >>> ... >>> >>> I don't know/remember if anyone brought this up previously, but there are >>> ways to connect to an Objective-C library in a flat C project. I've been >>> keeping this example handy in case I ever need to do it: >>> http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code. >>> >>> Erich Hoover >>> ehoo...@mines.edu >> > >
Fwd: Work on WineQuartz for MacOSX
Begin forwarded message: > From: Erich Hoover > Date: May 16, 2010 10:10:29 AM MDT > To: "C.W. Betts" > Subject: Re: Work on WineQuartz for MacOSX > > On Sun, May 16, 2010 at 10:02 AM, C.W. Betts wrote: > If memory serves, the main reason why there hasn't been any work done is > because of the dependency of Objective-C, which the project administrator has > said "no" to. > ... > > I don't know/remember if anyone brought this up previously, but there are > ways to connect to an Objective-C library in a flat C project. I've been > keeping this example handy in case I ever need to do it: > http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code. > > Erich Hoover > ehoo...@mines.edu
Re: Work on WineQuartz for MacOSX
If memory serves, the main reason why there hasn't been any work done is because of the dependency of Objective-C, which the project administrator has said "no" to. On May 16, 2010, at 9:31 AM, James Mckenzie wrote: > All: > > There was or is a quite lengthy thread on this project. > > What is the status of work? Any progress on Emmanuel's work from 2008? > > Thank you. > > James McKenzie > > > > >
Work on WineQuartz for MacOSX
All: There was or is a quite lengthy thread on this project. What is the status of work? Any progress on Emmanuel's work from 2008? Thank you. James McKenzie
