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

List:       koffice-devel
Subject:    QPainter/VPainter API, color models [Re: Explanation on WP vs DTP modes in KWord]
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-12-10 11:37:46
[Download RAW message or body]

On Sunday 01 December 2002 9:57 pm, Simon Hausmann wrote:
|  On Sun, Dec 01, 2002 at 07:32:19PM +0100, Dirk Schönberger wrote:
[...]
|  >
|  > I think it is the QPainter API that is the problem. QPainter provides no
|  > easy way to express things like
|  > - vector paths
|  > - complex fill algorithms like procedural patterns, gradients and the
|  > like - transparency effects
|  >
|  > There is simply no way to express it in the API. If I cannot express it,
|  > is is of no use if it could be possible for a backend to generate
|  > appropriate code.
|  >
|  > Example:
|  >
|  > QPainter has a method setColor (QColor), and a method drawBezier()
|  > (IIRC) What I would like to see is something like setColor (VColor),
|  > where VColor has an opacity property, which is used for setting
|  > transparency effects.
|
|  As far as I can see QColor uses QRgb for color storage, which in
|  turn can hold an opacity value (alpha channel) ?
|

It seems Xr's XrColor should be ok for the next few years of KDE/KOffice 
development.

Here is extract from my mail to <XFree86-devel> mailing list (which I have 
sent today, after making some analysis what kind of color definitions 
Xr/Xc/Xrender have)

*****************************************************************

I am also wondering wether Xrender's color model should be extended in order 
to accomodate floating point color values, and/or 64-bit RGBA.

Here are Mark's comments on this:
--------------------

Subject: Re: multicoloured cursor
Date: Thursday 31 October 2002 10:08 pm
From: Mark Vojkovich <MVojkovich@nvidia.com>
To: devel@xfree86.org
---------------------------------------------------------------------------------
> 
> I remember that someone also mentioned 16-bit alpha for some graphics 
> hardware.
> Are such chips/graphics cards available?
> Is it possible to get 64-bit ARGB on such cards (and in XFree86)?

   There were people on this list who were assuming that color
depths would increase and it was inevitiable that we'd eventually
have 64 bit color.  While that has happened, the changes have
been more radical than they were expecting.  It's not 64 bit
integer data but FLOATING POINT.  The PC graphics hardware that will 
start becoming widespread in 2003, will have 64, 96, 128 bit
floating point support, not wide integer support.  Under Linux
the only opportunity to expose this will likely be as PBuffers
in OpenGL.  Floating point is superior for rendering, but the
X-Window system, and even the RENDER extension do not have enough
color abstraction to support this type of thing.
---------------------------------------------------------------------------------

I have checked color definitions in Xr/Xc, and compared those to Xrender

Xr:  xrint.h
--------------------------------------
typedef struct _XrColor {
    double red;
    double green;
    double blue;
    double alpha;

    XcColor xc_color;
} XrColor;

Xc:  xc.h
--------------------------------------
typedef XRenderColor                    XcColor;

/usr/X11R6/include/X11/extensions/Xrender.h
--------------------------------------
typedef struct {
    unsigned short   red;
    unsigned short   green;
    unsigned short   blue;
    unsigned short   alpha;
} XRenderColor;

It looks like XrColor is "inline" with modern (and upcoming) graphics hardware 
(a-ka: DX9-capable graphics chips).
Shouldn't we have this XrColor in Xrender extension (and not in Xr extension)?
Than it would be possible to accelerate graphics for floating-point colors for 
modern hardware (ATI, NVidia, may be something else)

*****************************************************************

Let's see what would be answers.
There is no published RENDER ext. roadmap, so it's difficult to tell what 
Keith was planning about it.

I would prefer new color definitions (like: floating point colors) appear in 
Xrender extension, as there are many apps using Xrender already.
But as Xr extension is very light (and it's based on Xrender), having Xr as 
rendring backend wouldn't hurt KDE or QT.

There is a problem of compatibility with old X servers, though (< XF-4.3.0).
This problem can be solved by using Xc extension (client-side rendering).
Unfortunately, there is no code in Xc supporting Xr functionality at a moment 
(but it's in Carl Worth's TODO list)
As always with Open-Source: there is no prompted date when this code would be 
completed.


|  > What I also would like to see is full vector path composing methods,
|  > like
|  >
|  > VPainter painter;
|  > painter.moveTo(10.0, 15.0);
|  > painter.curveTo(10.0, 15.0, 20.0, 30.0, 20.0, 30.0);
|  > painter.lineTo(30.0, 100.0);
|  > painter.closePath();
|  > painter.setClipPath();
|  >
|  > If these methods (and others, as appropriate) are defined in the
|  > frontend, it is more or less possible to create this behaviour, with
|  > some effort also using QPainter calls as a backend.
|  > If it is not defined in the frontend, there is just no way to get such
|  > behaviour.
|
|  Ah, I see. I guess for extending the API one could indeed create a
|  new painter class that inherits from QPainter and uses the paint
|  device command space (everything > QPaintDevice::PdcReservedStop) to
|  pass the extended functionality to a backend?

Can you extend Qt in such a way that new color model(s) would be supported, 
too (64-bit RGBA, 64, 96, 128-bit floating point)?
I guess you can't do it without breaking backward compatibility.

|
|  > > Did you consider writing a new paint device that generates the
|  > > output you want? While probably still a hell of a lot of work I
|  > > could imagine that it is less work than changing existing code to
|  > > not use the QPainter API anymore.
|  >
|  > What I would like to promote is a new way of writing things (not really
|  > new, things like Postscript operators exist for how many years?) to
|  > screen or printer.
|  > As long as we have no quick backend for these, and a not stable API, I
|  > think it would be better if this API is used only on the places where it
|  > is absolutely needed, like in koffice/karbon, KSVG, and some SVG
|  > renderers, perhaps in KOffice (like e.g. KWord)
|  > Later, if better backends become available, like as part of the XRender
|  > extension in XFree, more parts can use this API.

This is very reasonable, IMO.

|  >
|  > A QPaintDevice can just create proper code for the operators QPainter
|  > supports.
|  >
|  [...]
|
|  Right, this is why the QPainter <> QPaintDevice couple is
|  extensible.
|
|  My point is that I believe it is much better to re-use the existing
|  QPainter API and extend it if necessary instead of starting a new
|  painter API just from scratch. There is much code written using
|  QPainter, developers are used to it.

If you use QPainter - you add dependency on Qt.
Which may be not really necessary for such purpose, as SVG or PostScript 
rendering.

IMO, we should consider option of making VPainter QT-independent.
NOTE that I am not saying that we should make it QT-independent.
I am saying that we should *consider* this.

There are several C++ based projects outside KDE/Qt tree (IceWM and BlackBox 
window managers, in particular)
It can be that those projects would be happy to use such C++ based API, too.

|
|  Simon
|  _______________________________________________
|  koffice-devel mailing list
|  koffice-devel@mail.kde.org
|  http://mail.kde.org/mailman/listinfo/koffice-devel

-- 

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes
http://kde2.newmail.ru/themes/
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]