[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    GNOME graphics and KDE
From:       Dirk_Schönberger <schoenberger () signsoft ! com>
Date:       1999-05-31 7:36:54
[Download RAW message or body]

Recently the GNOME project released some White Papers,
including something about their graphics architecture.

There are two concepts which I consider interesting, 
especially in respect to a availability for Qt/KDE, too.

The first is their panel architecture. I don't fully 
understand their concept, but I think, a similar 
functionality is available in Qt/KDE in form of the 
QScrollView, QwSpriteField and perhaps in the forthcoming
KIllustrator. But these classes are less exposed to any
potential developr, where in GNOME it is considered a core 
component.

The second is a high level 2D imaging API, which matches the 
features of Adobe Postscript, PDF, Bravo, the Java 2D Graphics 
API (and perhaps the XML based Scalable Vector Graphics 
as proposed by the W3-organization). In GNOME (or at least in 
their white papers) this functionality is carried out 
by their library libArt). 
As far as I see, there is no such functionality to be found 
in QT/KDE.
Key components of such a high level API I think of the follow:

- floating point based coordinated instead of integer for greater 
  flexibility
- a world coordinate system with transformation faciliies (rotate, 
  scale, translate, shear, arbitrary transformation by directly 
  accessing the transformation matrix)
- use of arbitrarily complex vector graphics paths, which are 
  consistently used for filled areas, the outlining of areas 
  (stroke) and for clipping.
- paths can consit of line segments, complex curve segments 
  (B-splines, Bezier-curves) and arc segments. The latter can be 
  implemented as curves. 
- paths can consist of several sub-path, there is calculated 
  a resulting path accorduing to some rules (winding rule, even-odd 
  rule). Especially the winding rule allows for graphical elements, 
  where parts are left out (e.g. a donut, an element of two 
  circular paths, where the inner part is cut out, allowing 
  other graphical elements to shine throught the donut).
- paths can be filled, either by a simnple colour, but also by an 
  extension mechanisms (pattern, IIRC), which allows for
  arbitrary filled areas.
- paths can be outlined or stroked, the used lines can have arbitrary 
  width (even different height and width, because they are subject 
  to coordinate transformations, e.g. scaling), The lines have other
  attributes, such as linecaps and miterlimits, which affect the
  way how the transistion of the segments of a path is handled).

Extension to this are e.g. an additional alpha channel, which allows for
paths which are partially trasparent.

Discussion welcome!

Dirk (schoenberger@signsoft.com)

[prev in list] [next in list] [prev in thread] [next in thread]