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

List:       kde-core-devel
Subject:    Re: Alpha blending with XRender prototype
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2001-04-15 21:26:44
[Download RAW message or body]



Lars Knoll wrote:
> 
> On Saturday 14 April 2001 00:54, Antonio Larrosa Jiménez wrote:
> > El Vie 13 Abr 2001 01:42, Richard Moore escribió:
> > > Hi all,
> > >
> > > I've got a first hack of alpha blending with the render extension
> > > working. Using Render means that the blending can be hardware
> > > accelerated, so ultimately I think this should replace the current client
> > > side blending we use for icons etc. for now though, this is just a
> > > prototype. It will not be ready for the 2.2 alpha. You can grab the
> > > example sources from
> > > http://www.ipso-facto.demon.co.uk/development/render/ I've also put a
> > > couple of screenshots there. To comppile the example extract it below
> > > into a standard KDE app template (because I didn't include the configure
> > > scripts etc just the Makefile.am).
> >
> > I thought about implementing that by myself some time ago (after doing the
> > client side blending), but then I saw that Qt 3.0 will do that by itself
> > (and it already does in the snapshots) so I think there's no need to
> > implement XRender based blending in kdelibs (in fact, the current classes
> > for alpha blending should go away when we change to Qt 3.0 as I suppose
> > that Qt already implements a client-based blending when X11 doesn't have a
> > Render extension) I suppose Bradley could correct me if I'm wrong.
> 
> You are wrong. Client side alpha blending is a mess, and _way_ to slow (it
> requires 2 round trips to the Xserver). We can't really add that to Qt. Qt
> will support alpha bending on platforms that support it (meaning XFree-4.x at
> the moment), but it will fall back to simple masking based on aplha values on
> older platforms. I think this is the more reasonable behaviour as everything
> else would just give the impression of Qt/KDE getting very slow. This merely
> due to the fact that once a feature is available, people will start using it
> without thinking about the consequences it may have on older hard/software.

Does this mean I should carry on working on a Qt/KDE interface to
XRender or not? I have most of the design for a basic wrapper done
and it is only a few days work to implement it. If it's in Qt 3
then I won't bother - though I might backport it.

Basically I see a few major features that can be provided:

- Easy access to all the Render operations (blending etc.)
- Hardware acceleration where available
- Rendering directly into any Drawable (possibly with a blend etc.)
- A place to start when the rasterisation part of Render is working.

I don't see an easy way for these features to be implemented in a
way that will work without Render being present.

Rich.

> 
> Regards,
> Lars
> 
> >
> > Sorry,
> >
> > Greetings,
> >
> > --
> > Antonio Larrosa Jimenez
> > KDE Core developer  - larrosa@kde.org
> > SuSE Labs developer - larrosa@suse.de
> > http://perso.wanadoo.es/antlarr
> > KDE - The development framework of the future, today.

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