[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The big divide - graphics contexts and window servers
From: |
Philippe C.D. Robert |
Subject: |
Re: The big divide - graphics contexts and window servers |
Date: |
Mon, 18 Mar 2002 09:59:20 +0100 |
On Sun, 17 Mar 2002, Adam Fedor wrote:
> I'd like to propose a reasonably radical change in the GNUstep backend
> structure. While thinking about how to implement better graphic
> rendering in GNUstep I realized that the current backend structure is
> not very clean. Currently it consists of functions that handle windows
> and events (which rarely change, at least on a single platform) and
> functions that handle graphics (of which there are numerous libraries
> available, even for the same platform). I think we should split these
> up, into say, a GSWindowServer object, which handles display(window) and
> event issues, and the current NSGraphicsContext, which just handles drawing.
>
> This is better, not only conceptually: NSGraphicsContext is really meant
> to handle drawing into a specific device (window, printer, etc), but
> also in reality: Most libraries handle graphics only, not window
> creation, etc. It also separates things that the normal developer can
> mess with (creating contexts, drawing into them), from things that are
> better handled through the AppKit interface (creating windows, handling
> events).
>
> This should even allow you to do things like ghostscript drawing into
> one window, OpenGL into another, etc (Although that sounds scary to
> me). Porting would be easier - graphics libraries typically run on many
> platforms - only the window/event handling needs to be ported.
Well, an OpenGL accelerated backend sounds very interesting to me..:-) If I
can help, let me know!
> On another topic, I've been trying to decide what is the best (first)
> graphics library I should implement in this structure. I've been leaning
> towards OpenGL, since it seems to be very well supported and does great
> antialiasing, among other things. And heck, you just can't waste enough
> time learning yet another graphics library ;-)
>
> The only problem is that it doesn't natively handle fonts, which is
> really important. There are libraries that add this capability to
> OpenGL, but the best ones are written in C++, which means I'll have to
> write some cumbersome wrappers (ok, NOW I want Objective-C++!).
>
> If anyone wants to help with this, let me know.
Let me know if you have some more concrete ideas etc. for the GL backend! I am
very interested in that!
-Phil
--
Philippe C.D. Robert | VNET# 559-1565
Core Rendering | Office: +41 (0)32 732 15 65
Silicon Graphics, Inc. | Home: +41 (0)31 302 45 22
- Re: The big divide - graphics contexts and window servers, (continued)
Re: The big divide - graphics contexts and window servers, Pete French, 2002/03/18
- Re: The big divide - graphics contexts and window servers, Jeff Teunissen, 2002/03/18
- Re: The big divide - graphics contexts and window servers, Philippe C.D. Robert, 2002/03/19
- Re: The big divide - graphics contexts and window servers, Jeff Teunissen, 2002/03/19
- Re: The big divide - graphics contexts and window servers, Philippe C.D. Robert, 2002/03/19
- Re: The big divide - graphics contexts and window servers, Jeff Teunissen, 2002/03/20
Re: The big divide - graphics contexts and window servers,
Philippe C.D. Robert <=
Re: The big divide - graphics contexts and window servers, Richard Frith-Macdonald, 2002/03/18