discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The big divide - graphics contexts and window servers


From: Adam Fedor
Subject: The big divide - graphics contexts and window servers
Date: Sun, 17 Mar 2002 15:59:07 -0700
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.7) Gecko/20020120

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.

---

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.



--
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                      | know how I hate the stuff.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]