[0x15e]

I can see three major places that need help:

1. Support EXIF orientation when reading images
   
2. Use threading to preload the next image immediately
   
3. Smooth out the sliding / zooming
   

None of these tasks should be very difficult.

The EXIF rotation can likely be done with APIs already provided by XBMC (used for regular photo viewing). As the situation is, photos taken with an iPhone, etc. are displayed upside down / sideways, etc. This should be as simple as reading the EXIF info and rotating the pic accordingly, before applying it to whatever you do to display it.

It looks like the screensaver currently waits until it's time to show the next pic before it loads it. This causes a noticeable gap / stutter when the pic is changing. I think if the next pic was already preloaded, this would be a non-issue.

As far as I can tell, all the movement is being done in script-python-slideshow.xml so the animation can be addressed in there without much actual code.

Can anyone point me to the right APIs for using that EXIF data so I can start looking at this?

Is there a preferred method of threading in addon development?

And where is the documentation that can explain what's going on in that xml file?

Thanks very much. With some pointers, I hope to have this screensaver working as well as the old one did in the near future.

[ronie]

I can see three major places that need help:

1. Support EXIF orientation when reading images
   
2. Use threading to preload the next image immediately
   
3. Smooth out the sliding / zooming
   

None of these tasks should be very difficult.

without some basic knowledge on the xbmc skinning engine and the way python addons interact with xbmc,
things may indeed seem to be easy...

so let me start by explaining how the current slideshow screensaver works.
basically all it does list the contents of a picture folder.

this means, the addon has no knowledge of the images itself. it does not know anything about image size, image orientation or whatever.
all it has is a list of paths to the image files.

it then passes the path of each image to xbmc one by one, at the interval defined by the 'time per image setting'.
xbmc will, in turn, load the image and display it on screen.

The EXIF rotation can likely be done with APIs already provided by XBMC (used for regular photo viewing). As the situation is, photos taken with an iPhone, etc. are displayed upside down / sideways, etc. This should be as simple as reading the EXIF info and rotating the pic accordingly, before applying it to whatever you do to display it.

nope, addons can not access any exif related api in xbmc.
and even if they could, this 'api' is currently limited in xbmc to the image section only.

as an example, to clarify things a bit, a skin for instance can display exif info if you're browsing your images inside the Pictures section of xbmc.
however, skins can not display exif info for your movie covers or fanart images in the Movie section of xbmc.

bottom line, if you need some exif stuff, it needs to be handles by the addon itself.
this means the addon will have to actually open the image file to be able to read the exif info.
an example on how to do this using the python PIL library can be found here:
http://www.blog.pythonlibrary.org/2010/0...ng-python/

once you've extracted the 'orientation' field from the image, you should be able to figure out if the image should be rotated or not.
the actual rotation needs to be handled by the gui though and not the addon.
thus, besides passing the path to the image to xbmc, you'll also have to pass a conditional rotate animation.

It looks like the screensaver currently waits until it's time to show the next pic before it loads it. This causes a noticeable gap / stutter when the pic is changing. I think if the next pic was already preloaded, this would be a non-issue.

while this currently is indeed an issue, threading won't help a single bit to address it.
remember, the addon does not load/pre-load any images at all. xbmc handles all that.

what needs to be done (and it's what i'm currently workin on) is pass the image path to xbmc
one second in advance. this gives xbmc some time to preload the image before the addon will trigger xbmc to display the picture.

As far as I can tell, all the movement is being done in script-python-slideshow.xml so the animation can be addressed in there without much actual code.

i'm unsure what problems you experience with the slide/zoom animations...
i've replied to your previous post about it, but haven't gotten any feedback from you:
http://forum.xbmc.org/showthread.php?tid...pid1279260

it's kinda hard to fix something when you don't know what needs fixing ;-)

if it's about the pan/zoom anims being too 'fast', the actual speed you see depends on whatever skin you use.
skins can define an 'animation speed multiplier' in their addon.xml file, which applies to each and every animation you see in the skin,
including the ones in the screensaver.
i've added some code to the version i'm working on that takes the skin value into account and adjusts the animation speeds accordingly.

another animation bug was addressed here:
http://forum.xbmc.org/showthread.php?tid=147524


as for the requested xml documentation, you should be able to find everything in the xbmc skinning manual:
http://wiki.xbmc.org/index.php?title=XBM...ing_Manual

there's not that much going on in script-python-slideshow.xml file though.
it just defines two image controls and applies some animations to it.

i'm currently moving some animation from the xml file to python script, so they can be adjusted dynamically.
documentation on adding animation in python can be found here: http://mirrors.xbmc.org/docs/python-docs...Animations

if you want to tweak the animations, i'd suggest reading this wiki article as well:
http://wiki.xbmc.org/index.php?title=Tweeners



i appreciate the feedback 0x15e and you're more than welcome to help out.
it never hurts to have an extra pair of eyes/brains on the code.

the current sourcecode can be found here:
screensaver.xbmc.slideshow

please note this is work in progress and likely to change over the next few days.

[0x15e]

Thanks for the response. Sorry I missed your other one. I must've forgotten to subscribe to that thread. Sorry for sounding a bit harsh in there but some comments like "not a priority for the devs and they probably won't work on it" had me a little irritated and I shot my mouth off.

Should I take this back over there to keep things in one place (or perhaps a mod merge the threads)?

so let me start by explaining how the current slideshow screensaver works.

Thanks, that definitely cleared some things up. I was under the impression that the addon was doing much more of the heavy lifting than it is.

I've coded a little against PIL before (building faxes from scratch, nothing fun) but haven't done anything with the EXIF data. I'll look into that and once I get a better understanding of XBMC's skinning system (and if you haven't done it already), I'll see if I can contribute some code there.
Edit: For what it's worth, I think PIL uses some native code. That might make it a pain to redistribute. Maybe something like this would be better.

I'll go ahead and address your responses to my earlier post:

Crashing XBMC: hasn't done that since RC2
Animation too fast: sounds like you have that covered
No crossfade in pan/zoom: there's a freeze on the old pic and then they switch nearly instantly. This is what I was trying to address with the multithreaded loading. The hang / lag length seems to vary based on the file size of the picture.
Overall polish: that was just a comment on the state of the screensaver in general. I understand now that it must've been put together in a hurry to fill the void left by the old one in time for the feature freeze.

[qkw24]

Also, it seems the images for the screensaver is cached, which leads to poor quality.
We should solve this. Eden's screensaver doesn't have this issue at all.