idea: display drivers

[C.W. Betts]

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".

[James McKenzie]

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

[Ben Klein]

On 7 February 2010 01:45, 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.

Isn't there a LOT of code that's intertwined with winex11, or did that
get separated out?

[C.W. Betts]

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

[Charles Davis]

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

[Stefan Dösinger]

> 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.

[James McKenzie]

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

[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

[Roderick Colenbrander]

> 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

[Reece Dunn]

On 7 February 2010 15:02, 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.
>
> 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

[Roderick Colenbrander]

On Sun, Feb 7, 2010 at 4:40 PM, Reece Dunn  wrote:
> On 7 February 2010 15:02, 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.
> >
> > 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

[David Gerard]

On 7 February 2010 15:40, Reece Dunn  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.

[Gert van den Berg]

On Sun, Feb 7, 2010 at 21:40, David Gerard  wrote:
> On 7 February 2010 15:40, Reece Dunn  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?

[David Gerard]

On 7 February 2010 20:23, Gert van den Berg  wrote:
> On Sun, Feb 7, 2010 at 21:40, David Gerard  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.

[Gert van den Berg]

On Sun, Feb 7, 2010 at 22:47, David Gerard  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

[James McKenzie]

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

[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