An idea that popped into my head when I was thinking about a Quartz (OS X) driver that perhaps there could be separate drivers for Quartz (OS X) and X11. Such drivers would include OpenGL and DirectX "Drivers".
C.W. Betts wrote:
An idea that popped into my head when I was thinking about a Quartz (OS X) driver that perhaps there could be separate drivers for Quartz (OS X) and X11. Such drivers would include OpenGL and DirectX "Drivers".
This has been shot down time and time again by Alexandre. However, picking up the old Winequartz.dll code and looking at it has been a project that I am interested in. The code is available from Sourceforge.net. James McKenzie
On 7 February 2010 01:45, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
C.W. Betts wrote:
An idea that popped into my head when I was thinking about a Quartz (OS X) driver that perhaps there could be separate drivers for Quartz (OS X) and X11. Such drivers would include OpenGL and DirectX "Drivers".
This has been shot down time and time again by Alexandre. However, picking up the old Winequartz.dll code and looking at it has been a project that I am interested in. The code is available from Sourceforge.net.
Isn't there a LOT of code that's intertwined with winex11, or did that get separated out?
Is is just because of the Objective-C code? Would it be safe to make C functions that would call Objective-C? Such as: cheader.h: typedef struct struct1 struct1; cfuncCreate(struct1 *s); cfunc1(); cfunc2(); cfuncDestroy (struct1 *s); cfile.m: @interface WHQFunc { } -(id)init; -(void)dealloc; @end struct { WHQFunc *ObjC; int ids; }struct1; @implementation WHQFunc -(id)init { return [super init]; } -(void)dealloc { [super dealloc]; } @end cfunc1() { } cfunc2() { } cfuncCreate(struct1 *s) { s = malloc(sizeof(struct1)); [[s->ObjC alloc] init]; } cfuncDestroy (struct1 *s) { [s->ObjC release]; free(s); } On Feb 6, 2010, at 7:45 AM, James McKenzie wrote:
C.W. Betts wrote:
An idea that popped into my head when I was thinking about a Quartz (OS X) driver that perhaps there could be separate drivers for Quartz (OS X) and X11. Such drivers would include OpenGL and DirectX "Drivers".
This has been shot down time and time again by Alexandre. However, picking up the old Winequartz.dll code and looking at it has been a project that I am interested in. The code is available from Sourceforge.net.
James McKenzie
C.W. Betts wrote:
Is is just because of the Objective-C code? Would it be safe to make C functions that would call Objective-C? Such as: cheader.h: typedef struct struct1 struct1; cfuncCreate(struct1 *s); cfunc1(); cfunc2(); cfuncDestroy (struct1 *s);
cfile.m: @interface WHQFunc {
} -(id)init; -(void)dealloc; @end struct { WHQFunc *ObjC; int ids; }struct1; @implementation WHQFunc
-(id)init { return [super init]; } -(void)dealloc { [super dealloc]; } @end
cfunc1() {
} cfunc2() {
} cfuncCreate(struct1 *s) { s = malloc(sizeof(struct1)); [[s->ObjC alloc] init]; } cfuncDestroy (struct1 *s) { [s->ObjC release]; free(s); }
Working on it. The problem is that there can't be any Objective-C code in Wine. At all. Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any language other than pure, procedural C. I wanted to wait until it was finished, but I may as well announce it now. I'm working on a new tool to create pure C bindings to Objective-C frameworks. That way, you can use an Objective-C framework (like the Cocoa Foundation and AppKit frameworks) from C. There is a even a companion framework that lets you define your own classes and create instances of them--without writing a single line of Objective-C. If you'll be patient, I'll be finishing it soon, and I'll post the source and binaries somewhere so you can use it. My intent is precisely, among other things, to use this to create a Quartz driver that will work in 64-bit (because the Carbon UI stuff doesn't work in 64-bit). Chip
The problem is that there can't be any Objective-C code in Wine. At all. Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any language other than pure, procedural C. Alexandre has said that you can put objective C code into wine, but only if this code is properly abstracted from the other parts of the quartz driver. E.g. by a simple binding wrapper that does nothing but wrap Objective C to C bindings. The requirement is that somebody can read and understand the Quartz driver without knowing Objective C.
The biggest obstacle to merging a Quartz driver is cleaning up the user32 driver interface. Objective C is a minor issue with a pretty straightforward solution. Currently nobody knows what a proper user32 driver interface would look like.
Stefan Dösinger wrote:
The problem is that there can't be any Objective-C code in Wine. At all. Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any language other than pure, procedural C.
Alexandre has said that you can put objective C code into wine, but only if this code is properly abstracted from the other parts of the quartz driver. E.g. by a simple binding wrapper that does nothing but wrap Objective C to C bindings. The requirement is that somebody can read and understand the Quartz driver without knowing Objective C.
The biggest obstacle to merging a Quartz driver is cleaning up the user32 driver interface. Objective C is a minor issue with a pretty straightforward solution. Currently nobody knows what a proper user32 driver interface would look like.
It might be a good idea to look at the code used in other projects to get a good starting point. OpenOffice.org did an implementation of an Aqua driver based from X11 code. Took SEVERAL years to do. James McKenzie
Charles Davis wrote:
C.W. Betts wrote:
Is is just because of the Objective-C code? Would it be safe to make C functions that would call Objective-C? Such as: cheader.h: typedef struct struct1 struct1; cfuncCreate(struct1 *s); cfunc1(); cfunc2(); cfuncDestroy (struct1 *s);
cfile.m: @interface WHQFunc {
} -(id)init; -(void)dealloc; @end struct { WHQFunc *ObjC; int ids; }struct1; @implementation WHQFunc
-(id)init { return [super init]; } -(void)dealloc { [super dealloc]; } @end
cfunc1() {
} cfunc2() {
} cfuncCreate(struct1 *s) { s = malloc(sizeof(struct1)); [[s->ObjC alloc] init]; } cfuncDestroy (struct1 *s) { [s->ObjC release]; free(s); }
Working on it.
The problem is that there can't be any Objective-C code in Wine. At all. Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any language other than pure, procedural C.
I wanted to wait until it was finished, but I may as well announce it now. I'm working on a new tool to create pure C bindings to Objective-C frameworks. That way, you can use an Objective-C framework (like the Cocoa Foundation and AppKit frameworks) from C. There is a even a companion framework that lets you define your own classes and create instances of them--without writing a single line of Objective-C.
If you'll be patient, I'll be finishing it soon, and I'll post the source and binaries somewhere so you can use it. My intent is precisely, among other things, to use this to create a Quartz driver that will work in 64-bit (because the Carbon UI stuff doesn't work in 64-bit).
Chip: Emmanuel's code is available from Sourceforge. It is a good starting point for this. If you want, send me what you have so far for testing purposes. It would be great to have a native MacOSX windowing system. James McKenzie
Emmanuel's code is available from Sourceforge. It is a good starting point for this. If you want, send me what you have so far for testing purposes. It would be great to have a native MacOSX windowing system.
James McKenzie
The design of the old quartz driver is not correct. I remember that Alexandre commented that a lot of code which was in it doesn't make sense for a quartz driver but only for X11. Before a quartz driver can be written we really need a dib engine. It will make writing another driver much easier and much more code would be shared. Thinking a few steps further I also think that at some point the current X11 driver needs to be redesigned for modern windows version (we would get a classic winex11 and a modern one). The modern one would in my opinion only be responsible for creating windows, font rendering but the rest would all be done using OpenGL. This way the rendering code could also work on OSX and only window management stuff would be needed. Roderick
On 7 February 2010 15:02, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
Emmanuel's code is available from Sourceforge. It is a good starting point for this. If you want, send me what you have so far for testing purposes. It would be great to have a native MacOSX windowing system.
James McKenzie
The design of the old quartz driver is not correct. I remember that Alexandre commented that a lot of code which was in it doesn't make sense for a quartz driver but only for X11. Before a quartz driver can be written we really need a dib engine. It will make writing another driver much easier and much more code would be shared.
Thinking a few steps further I also think that at some point the current X11 driver needs to be redesigned for modern windows version (we would get a classic winex11 and a modern one). The modern one would in my opinion only be responsible for creating windows, font rendering but the rest would all be done using OpenGL. This way the rendering code could also work on OSX and only window management stuff would be needed.
In general, this seems to be the best approach. I do have a few questions, though: 1/ Does this mean that OpenGL is required for all GDI calls, not just D3D? If so, it will exclude people who don't have OpenGL support (e.g. are using the vesa, nv, or nouveau drivers). 2/ What will the performance of GDI32 calls be like? There are various comments that the Vista architecture does not optimise GDI32 calls, so applications that use these are slower. References: * http://www.theregister.co.uk/2007/12/04/vista_vs_xp_tests/ * http://blogs.msdn.com/nickkramer/archive/2006/04/07/571162.aspx (primitives now rendered in software) * http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx NOTE: Windows 7 appears to have reversed part of the Vista trend by hardware accelerating as many of the GDI calls as they could References: * http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphi... * http://www.pcpro.co.uk/blogs/2009/05/07/windows-7-gdi-performance-the-big-tr... - Reece
On Sun, Feb 7, 2010 at 4:40 PM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
On 7 February 2010 15:02, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
Emmanuel's code is available from Sourceforge. It is a good starting point for this. If you want, send me what you have so far for testing purposes. It would be great to have a native MacOSX windowing system.
James McKenzie
The design of the old quartz driver is not correct. I remember that Alexandre commented that a lot of code which was in it doesn't make sense for a quartz driver but only for X11. Before a quartz driver can be written we really need a dib engine. It will make writing another driver much easier and much more code would be shared.
Thinking a few steps further I also think that at some point the current X11 driver needs to be redesigned for modern windows version (we would get a classic winex11 and a modern one). The modern one would in my opinion only be responsible for creating windows, font rendering but the rest would all be done using OpenGL. This way the rendering code could also work on OSX and only window management stuff would be needed.
In general, this seems to be the best approach. I do have a few questions, though:
1/ Does this mean that OpenGL is required for all GDI calls, not just D3D? If so, it will exclude people who don't have OpenGL support (e.g. are using the vesa, nv, or nouveau drivers).
I think that in the end we would need 2 drivers. One classic x11 in the current design (adjusted a bit were possible) and one which follows the Win7-design using OpenGL. The idea would be to let Wine perform the majority of GDI calls in software (both the DIB stuff and a big part of the DDB calls). Like Win7 we would accelerate common GDI functions like AlphaBlend, BitBlt/StretchBlt (only the common ROPs like SRCBLT and a few others) and ColorFill on the gpu using opengl. See http://msdn.microsoft.com/en-us/library/dd434692.aspx for what Win7 accelerates. When using OpenGL we would emulate DIBSections using PBOs and perhaps GLX_texture_from_bitmap is of any use as well in case of X11.
2/ What will the performance of GDI32 calls be like? There are various comments that the Vista architecture does not optimise GDI32 calls, so applications that use these are slower.
Vista performed all of GDI in software but Win7 accelerates a couple of common calls which I mentioned above using the GPU. Performance could be quite good. So to summarize a win7-style wine rendering architecture would perform all DIB rendering in software ('the dib engine') and also the non-common DDB calls. Other calls are accelerated using OpenGL. A x11/quartz/some_other_os driver would be used for window creation, window management, input and likely font rendering. Roderick
On 7 February 2010 15:40, Reece Dunn <msclrhd(a)googlemail.com> wrote:
1/ Does this mean that OpenGL is required for all GDI calls, not just D3D? If so, it will exclude people who don't have OpenGL support (e.g. are using the vesa, nv, or nouveau drivers).
As I understand it, current Xorg does OpenGL in software on any video chipset it supports ... vvvveeerrryyy ssslllooowwwlllyyy, but it does it. - d.
On Sun, Feb 7, 2010 at 21:40, David Gerard <dgerard(a)gmail.com> wrote:
On 7 February 2010 15:40, Reece Dunn <msclrhd(a)googlemail.com> wrote:
1/ Does this mean that OpenGL is required for all GDI calls, not just D3D? If so, it will exclude people who don't have OpenGL support (e.g. are using the vesa, nv, or nouveau drivers).
As I understand it, current Xorg does OpenGL in software on any video chipset it supports ... vvvveeerrryyy ssslllooowwwlllyyy, but it does it.
But what about other X servers, such as Xsun, Xvnc, remote Xming sessions, etc?
On 7 February 2010 20:23, Gert van den Berg <wine-devel(a)mohag.net> wrote:
On Sun, Feb 7, 2010 at 21:40, David Gerard <dgerard(a)gmail.com> wrote:
As I understand it, current Xorg does OpenGL in software on any video chipset it supports ... vvvveeerrryyy ssslllooowwwlllyyy, but it does it.
But what about other X servers, such as Xsun, Xvnc, remote Xming sessions, etc?
No idea, sorry. Xsun is on extended (life-)support with Sun moving to Xorg (and Alan Coopersmith from Sun being one of the main Xorg developers). Xming is Xorg compiled for mingw. Xvnc, no idea. - d.
On Sun, Feb 7, 2010 at 22:47, David Gerard <dgerard(a)gmail.com> wrote:
No idea, sorry. Xsun is on extended (life-)support with Sun moving to Xorg (and Alan Coopersmith from Sun being one of the main Xorg developers). Xming is Xorg compiled for mingw
Xming: An ancient version of Xorg (at least for the free version) (6.9) I have seen Solaris 10 default to Xsun in some cases... (Although Xorg is available...) What I meant is that requiring OpenGL might lose some portability... (Needing an X server for console apps is irritation, but solvable using something like Xvnc. This becomes a lot harder to solve if you need an X server with OpenGL) Gert
Roderick Colenbrander wrote:
Emmanuel's code is available from Sourceforge. It is a good starting point for this. If you want, send me what you have so far for testing purposes. It would be great to have a native MacOSX windowing system.
James McKenzie
The design of the old quartz driver is not correct. I remember that Alexandre commented that a lot of code which was in it doesn't make sense for a quartz driver but only for X11. Before a quartz driver can be written we really need a dib engine. It will make writing another driver much easier and much more code would be shared.
I agree with the fact that the quartz.dll is not functionally accurate. However, the conversation started (I think) on building a native driver for MacOSX, which should not use an X11 code. This is why I pointed out the fact that it took YEARS (and I really mean this 2003-2009) to get a native version of OpenOffice.org to function properly. Your assessment may be proper in that the X11 version of quartz.dll may need to be completely redone to make this easier and to facilitate movement to other windowing systems.
Thinking a few steps further I also think that at some point the current X11 driver needs to be redesigned for modern windows version (we would get a classic winex11 and a modern one). The modern one would in my opinion only be responsible for creating windows, font rendering but the rest would all be done using OpenGL. This way the rendering code could also work on OSX and only window management stuff would be needed.
Correct. But why keep the old stuff around? It might be confusing to the Wine beginner. James McKenzie
C.W. Betts wrote:
Is is just because of the Objective-C code? Would it be safe to make C functions that would call Objective-C? Such as: cheader.h: typedef struct struct1 struct1; cfuncCreate(struct1 *s); cfunc1(); cfunc2(); cfuncDestroy (struct1 *s);
cfile.m: @interface WHQFunc {
} -(id)init; -(void)dealloc; @end struct { WHQFunc *ObjC; int ids; }struct1; @implementation WHQFunc
-(id)init { return [super init]; } -(void)dealloc { [super dealloc]; } @end
cfunc1() {
} cfunc2() {
} cfuncCreate(struct1 *s) { s = malloc(sizeof(struct1)); [[s->ObjC alloc] init]; } cfuncDestroy (struct1 *s) { [s->ObjC release]; free(s); }
No .m files....There can be no code that cannot compile or be ignored on other *NIX platforms. James McKenzie
participants (9)
-
Ben Klein -
C.W. Betts -
Charles Davis -
David Gerard -
Gert van den Berg -
James McKenzie -
Reece Dunn -
Roderick Colenbrander -
Stefan Dösinger