discuss-gnustep
[Top][All Lists]
Advanced

[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




reply via email to

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