[Kde-graphics-devel] Status update
dan.duley at verizon.net
Mon Jan 3 18:01:22 CET 2005
I haven't looked at kcanvas or kpainter much, I just got KDE CVS going and
didn't co kdenonbeta yet. I'll definitely have a look. I mostly just looked
at the SVG stuff and Karbon. My earlier attempts at MosfetPaint had a painter
based on the svg icon painter ;-)
The main problem with doing an Arthur backend for images is, as I said, the
brushes. Pixmapped brushes will suck because they are pixmaps, not images.
This means they are on the X server in whatever the server depth is. Not only
does this mean you need to convert the pixmap to an image before using them
on your own image, (bad performance), but it will be truncated or dithered if
your display is not truecolor, (ie 16bpp). That is the biggest problem IMHO.
You can always cache pixmaps as images in your canvas backend to increase
performance, but if the X server is running at 15 or 16bpp your going to lose
color resolution. If you guys are old school you'll remember XPaint always
warning about this ;-)
You'd want a brush class that has it's own image, not an X pixmap. Fonts are
another problem, too...
As for being directly coupled to something like libart, I don't see much
problem with that. Libart is really useful. Who wants to recode all those AA
graphics and path stuff? Not me ;-) As long as it's toolkit independent and
can handle normal BGRA scanlines, (which it can), I'm happy.
On Monday 03 January 2005 09:26 am, Hans Oischinger wrote:
> On Monday 03 January 2005 16:16, Dirk Schönberger wrote:
> > The other attempts I have seen are mostly directly coupled to a lowlevel
> > rendering library like AGG or libart.
> KCanvas in kdenonbeta also provides multiple targets and is already quite
More information about the Kde-graphics-devel