[Kde-graphics-devel] KImageF ?

[Ignacio Castaño]

On Tuesday 29 November 2005 07:11 am, Zack Rusin wrote:
> On Tuesday 29 November 2005 10:45, Brad Hards wrote:
> > Has anyone thought about a KDE class to handle data like the nvidia
> > "half" data type (16-bit per channel, floating point).
>
> Don't look at Cg, it's going away.

What makes you think that way? We have no plans on stop supporting Cg, in 
fact, Cg 1.5 is going to be our best release so far.

My only concern with Cg is the lack of a free implementation, but there's 
nothing stopping developers writting their own implementation. We tried to 
encourage that by releasing the compiler frontend and "Cg" is not protected 
by any trademark so that people could write their own implementations and 
still call them "Cg".

http://developer.nvidia.com/object/cg_compiler_code.html


> > I'm thinking about how we can handle high definition images in a
> > sensible way. Ideally it would be accelerated on hardware that can
> > support it, and would still work OK for people with 8bit ARGB
> > hardware.
>
> Ideally I'd like to have a 16bit channel support in Qt. The future of
> KImageEffect looks as follows right now:
> a) scrap it,
> b) create OpenGL SL to C compiler and finish SL support in Mesa,
> c) create image manipulation library where /all/ algorithms are
> implemented with SL.
> d) build a simple graph library on top of it. So you can mix and match
> the algorithms from C as filters.
>
> If the hardware supports fragment shaders, we're getting hardware
> accelerated image manipulation library of the bat, if it doesn't we're
> getting software fallbacks for free. It'd be one codebase that unifies
> it all.

You can currently use the arbfp target of the Cg compiler and use the Mesa 
software implementation. Cg 1.4 also has a software backend, but it's very 
slow and currently does not support texture sampling, so it's not very useful 
for that purpouse.

-- 
Ignacio Castaño
castanyo at yahoo.es