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