[Digikam-devel] new KIPI plugin (image viewer)

[Colin Guthrie]

Markus Leuthold wrote:
> I tried to send it to kde-imaging too, but I got rejected

Ahh well. There has been a policy change not too long ago, so perhaps
you'll need to subscribe now?

>> If you do and you have time, could you take a look at:
>> http://bugs.kde.org/show_bug.cgi?id=102021
>>
>> I've been wanting that for ages :)
>>
> really nice, I like that wish with the dualscreen setup. Shouldn't be too 
> difficult to implement. And yes, you're right, transitions must blend on 
> moving images, I agree. I didn't make up my mind yet on the Ken Burns effect, 
> which also keep on panning or zooming AFTER the transition is finished
> (http://en.wikipedia.org/wiki/Ken_Burns_Effect). 

I really like the apple implementation if that's any help. I think it
keeps the panning AND zooming after the transition, so the photo itself
is *always* moving and zooming, even when it blends into another.

Also it has dual screen support that shows two (and sometimes four
during transitions!) images symultaniously (each display acts as a
"photo frame").

>> Is this going to conflict in anyway with Compiz/Beryl or similar?
> as far as I understand, there are still issues with OpenGL apps on next-gen 
> window managers as Beryl. As long as the OpenGL command are not directly 
> passed to the driver, it will result in a (probably small) performace drop. 
> But they're working on it... I didn't get Beryl running yet due to only 
> having 32mb video mem.

Cool, I thought it should be OK, but e.g. Myth somehow borked my Xgl and
now my AIGLX setup :( Hey ho I'm sure your stuff will work OK.

> I didn't figure out yet what the best strategy is for displaying images: I can 
> either download the entire 20MB raw data (for a 5mp jpg) to the texture ram 
> and let the GPU downsample the image or I can downsample the image with 
> QImage::scale() to screen resolution and then only download about 6MB to tex 
> mem. Since I have a very slow AGP setup, the latter is faster on my system. I 
> only load the entire 20MB to texture ram as soon as I perform zoom 
> operations. Therefore, if you don't zoom you shouldn't run out of memory with 
> Beryl. But I'd be interested how it acts under Beryl.

I'll let you know when I get it working again (a non-beryl related Mesa
issue with my current Mandriva Cooker install!).

Cheers just now.

Also Angelo is right about slideshow maintainership. Once you finish of
putting the features of slideshow into your plugin we can maybe
deprecate slideshow completely for the next release.

If you are quick with a semi stable version of your plugin, it could
even make it into 0.1.3 release. WDYT Angelo? I wouldn't want to delay
0.1.3 but perhaps a totally new plugin can sneak in without as much
testing? It could just be called a "preview release" of the plugin and
as such come with no warrenty? Or is that just bad PR?

Col.