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

List:       kde-devel
Subject:    Re: QPainter and multi-component beziers
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2003-03-10 22:26:16
[Download RAW message or body]

> > QPainterPaintDevice is supposed to be a real short term solution.
> > I think you need a common API for screen output and print output.
> > But it should be more printer oriented than oriented to putting pixels
to
> > screen. A nice API is something like Display Postscript or MacOS X's
Quartz
> > API, instead of, like X core API, GDI or the like.

> Are you sure that works?
> As far as I have can imagine, to do high quality, high speed screen
> rendering, you need good pixel-based API. Despite the SVG madness
> everywhere, I still think, you eventually have to manipulate single
> pixels. And optimize your program data structures to manipulate
> the pixels well. This just does not mix well with generic vector
> based renderer, printing eventually has to provide, to be reasonably
> device idependent.

But that's what a render API is for, something like libart. KPainter is more
or less for defining a high level interface, which can be used to render
using different backends. A backend can define needed
emulation, if a feature is not natively supported, or it can "fudge" soe
things. E.g. I try to implement a SVG renderer as part of my KPainter
project. SVG defines that coordinates are in the middle of the four
neighbouring pixels. This leads to blurred pixels in the anti-aliased case,
because each of the four neighbouring pixels has to be rendered with a
quarter of the pixel value. I am able to define a rendering hint in
LibartPaintDevice, which leads to better rendering results by applying an
implicit global translation by (-.5, -.5), i.e align to pixel. The rest of
the rendering is still done by libart.

> Similarly graphic accelerators have IMHO very limited use for 2D screen
> rendering, because they are oriented towards 3D. I.e. they blur image
> instead of displacing primitives to integral places. And they expect
> really lame triangle-based image description anyways.

I agree, but I think e.g. OpenGL provides decent 2D rendering as well? At
least I have seen proposals to implement things like 2d GUIs using OpenGL.
The triangle-based description allows for fast rendering, but I think for
higl-level graphics it is not really useable. You need another API for that.
AFAIK the Xrender extension / Xr also uses polygonal primitives (I think
trapezoids) for rendering. There is still defined a high level API which
allows for Postscript like multi-component beziers.

Regards
Dirk



 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]