[Kde-graphics-devel] Status update

Mosfet 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
> functional.
> Greets,
>  Hans

More information about the Kde-graphics-devel mailing list