Normal slideshow (activated using the "view fotos in a slideshow" button) works great but if I activate slideshow from within fullscreen mode, the photos are displayed "fit to screen width", which results in large areas of the photo being cut off (tested with SVN build)

Also, before the slideshow begins playing, I see a white screen for a few seconds. 

*** Bug 428435 has been marked as a duplicate of this bug. ***

From 428435:

> Well, Slideshow mode (F5) works fine.
> 
> But activating Slideshow from within Fullscreen (F11) things get broken:
> 
> A) Photos are stretched to screen width, Photos that are taller than wide will
> get cut off. This scaling does NOT happen in F5-Slideshow mode.
> 
> B) Slideshow transition effects are shown AFTER the picture has changed,
> meaning: Picture changes from A to B and immediately afterwards the transition
> effect kicks in, changing to that pic again. In the case of the cube
> transition, the pic on the front side is changed to the new one and THEN the
> cube rotates, showing the same pic on both visible faces.
> 
> I'm running an NVidia GeForce 7950 with 9746 drivers. Running with Compiz right
> now, but I tried Metacity (without comp manager) and that doesn't change a
> thing.

*** Bug 400374 has been marked as a duplicate of this bug. ***

From 400374:

> while using the nvidia glx drivers, the pictures in slideshow looks weird,
> sometimes very clear, sometimes with a color overlay (yellow and purple are the
> more common patterns)
> if I use libGL.so.1.2.xlibmesa (e.g.), it works well
> 
> don't know if it's a problem in f-spot, in nvidia-glx or in somewhere inbetween
> 

There's an ubuntu bug too here: https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/130085

"F-Spot zoom in fullscreen mode does'nt work.
To reproduce:
*Turn on Compiz
*Open F-Spot
*Click "Fullscreen"
*Zoom in on the displayed photo and try to drag it by keeping your hand on the left mouse button and moving the mouse.

The picture also becomes distorted (lines etc. appear through the photo)"

the bug also have a screenshot attached in case you want to see it.

re #6 I can't reproduce the zoom problems.

re #3:
The problem described in A) now also occurs for me when directly going into slideshow mode (F5)
Problem B) does not happen for me


Furthermore, my f-spot crashes when I start a slideshow and then exit it. I have Xorg with ati driver without compiz running:

open uri = file:///data/pics/2007/09/13/00035758.jpg
open uri = file:///data/pics/2007/09/13/00035758.jpg
Disposing 1 IsTexture 1
Done Disposing 1
open uri = file:///data/pics/2007/09/13/00035758.jpg
open uri = file:///data/pics/2007/09/13/00035758.jpg
max texture size 2048 scaling to 0,7191011
scaling image 2048 x 1536
The program 'f-spot' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 5238 error_code 2 request_code 145 minor_code 9)

On Ubuntu Gutsy, compiz on, I get flashes when starting the slideshow (not the simple fullscreen). First, the photo appears in a little rectangle in the top-left corner of F-Spot's window, and sometimes it goes to fullscreen, sometimes it displays the slideshow in this little rectangle (the navigation bar appears/disappears when I move the mouse over it).
When it manages to go to fullscreen, I still get troubles:
- my panel applets (and other windows) often show up for half a second on the top of the photos, leaving grey rectangles
- the navigation bar is not transparent on its borders (although it is in simple fullscreen mode)
- many times F-Spot is not responding and I get a completely grey-brown screen

Note my hard disk is working much before a slideshow (~4 secs), and not before a simple fullscreen.

Cleaned log: (just ask for more info)
$ f-spot
Initializing Mono.Addins
Starting new FSpot server
Query: XXXXX

(f-spot:20954): Gtk-WARNING **: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem

(f-spot:20954): Gtk-WARNING **: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
Query: XXXXXX
item changed
open uri = file:XXXX

(f-spot:20954): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.
open uri = file:XXXX
item changed
open uri = file:XXXX
max texture size 2048 scaling to 0,7272727
scaling image 1536 x 2048
item changed
open uri = file:XXXX
max texture size 2048 scaling to 0,7272727
scaling image 1536 x 2048

Created attachment 96815 [details] [review]
patch to address scaling in slideshow properly

Hi,

I created a patch that addresses the problem described in A) from comment #3. The graphics are now scaled properly to fit in the screen.

However it's not quite perfect because I had a hard time with OpenGL: outside the texture the border of the texture is stretched out to the border of the screen. That makes it look very ugly. I tried to fix this too with some glTexParameter calls, but it still doesn't work.
If someone could give me a hint how to solve this I'd be glad, because I haven't found something useful on the net.

Peter

PS: please report any coding style issues, if there are any.

Created attachment 97201 [details] [review]
slideshow handles fitting correctly, no "from-white-to-image" transition anymore

This patch corrects the fit-function so that images correctly fit in the screen (no pixel bleeding to the edge anymore, as it was in my patch before).
Additionally it fixes the bug, where the first transition of the slideshow translates from a white screen to the image.

Created attachment 97205 [details]
Screenshot

The latest patch corrects the change-image-then-animate problem I was seeing. I *think* this is all fixed now BUT: for some reason I cannot get fullscreen mode to work anymore (it just says fullscreen in the window list as another "window") and slideshows just display "minimized" (see window)

But this is unreleated to the patch, the same happens for unpatched trunk. Any idea about this?

Again, with the patch applied, the slides animate correctly.

The problem was caused by compiz' workaround module. After disabling "legacy fullscreen fix" compiz fullscreen/slideshow works fine now. Thanks Peter, hope to see your patch on trunk soon!

Looks great, works fine !

before committing it to trunk, I'm just wondering why you're invalidating 'next' twice and preloading it twice also...

s

Just a question: why does the transitions only have effect if slideshow mode is on? I guess for just browsing next/previous in fullscreen the transition effects should be enabled, also? 

(In reply to comment #16)
> Just a question: why does the transitions only have effect if slideshow mode is
> on? I guess for just browsing next/previous in fullscreen the transition
> effects should be enabled, also? 

the fullscreen mode (not during slideshow) is not driven by OpenGL. That's why.

the first call involves the next property while the second involves the Next-get/set function.
after those 2 calls both previous and next reference the current texture (using preload).

I didn't want to change too much of the code because I wasn't sure what the author had in mind when creating the Next- and Previous-get/set function. I think the best solution is to delete the get/set functions completely and just use the properties directly, which is no loss in elegance but rather makes the code more transparent (and much shorter, too).

I'll submit that patch tonight so you can decide which one you like more.

(In reply to comment #18)
> the first call involves the next property while the second involves the
> Next-get/set function.
> after those 2 calls both previous and next reference the current texture (using
> preload).

y, I know that. I wondered if both were usefull...
 
> I didn't want to change too much of the code because I wasn't sure what the
> author had in mind when creating the Next- and Previous-get/set function. I
> think the best solution is to delete the get/set functions completely and just
> use the properties directly, which is no loss in elegance but rather makes the
> code more transparent (and much shorter, too).

don't remove the accessors...

(In reply to comment #19)
> (In reply to comment #18)
> > the first call involves the next property while the second involves the
> > Next-get/set function.
> > after those 2 calls both previous and next reference the current texture (using
> > preload).
> 
> y, I know that. I wondered if both were usefull...

maybe next = null; is not useful, because it's null in OnRealize anyway (I don't know if properties are initialized automatically).
Next = null; is definitely useful because it shifts the current texture in next to previous and sets next = null;

but maybe less confusing and better is to just write
previous = CreateTexture();
next = CreateTexture();

without using the accessors at all in OnRealize

> > I didn't want to change too much of the code because I wasn't sure what the
> > author had in mind when creating the Next- and Previous-get/set function. I
> > think the best solution is to delete the get/set functions completely and just
> > use the properties directly, which is no loss in elegance but rather makes the
> > code more transparent (and much shorter, too).
> 
> don't remove the accessors...
> 

ok.

Peter... 

ah, your patch address two issues !

am ok with the resizing solution, but even if it works, the solution for the previous/next issue is not clean enough... :)

I'm pushing the first part of the patch right now...

patch #97021 partially committed

(In reply to comment #21)
> Peter... 
> 
> ah, your patch address two issues !
> 
> am ok with the resizing solution, but even if it works, the solution for the
> previous/next issue is not clean enough... :)

I agree. I'll look for a better solution real soon!

> I'm pushing the first part of the patch right now...

I'm very happy with that because it's my first open source contribution :)

> I'm very happy with that because it's my first open source contribution :)

Congratulations !!! 

Created attachment 97365 [details] [review]
Another Patch to fix the "from-white-to-image" transition.

I still don't like the accessors because they're somewhat non-intuitive to use. 
They do a lot of things automatically, but not everything, so in the end you have to know their implementation anyway.
Setting Next to a value a user wouldn't expect that this involves Previous to be set also...
I think the cleanest solution is to provide two methods:
InitTextures and ShiftTextures which both access the properties directly. The first used in OnRealize, the latter used in HandleItemChanged. They encapsulate all functionallity needed.
Just an idea...

sorry, I didn't saw your patch earlier :( I committed an alternate solution to fix the prev/next issues in r3432.

Am closing this bug, all of the issues being addressed.

Open a new bug if you stil lhave a problem with a part of this.

Please don't close it. The slideshow still starts with a fade from a white screen after the first image. I think this is still not fixed in svn head. At least it doesn't work properly in my case.

I was busy with DVDSlideshow Extension that's why I didn't pay attention to this bug anymore. If I have time some time soon, I'll fix it.

Hi all, 

I'm experimenting some issues with the fullscreen mode and the slideshow one. They both appear in the bottom-left cornoer of my screen, in a small rectangle, like explicated before.

Only sometimes do they get in full screen.

I start these modes via the main window (the slideshow button and the fullscreen button in the top bar of F-spot). Even with the F keys, it does the same thing.

I see that there is some files (patches) attatched to this bug, can I install them? If yes, how do I proceed? If no, what do I have to do to correct this bug? Do I have to wait for the patches to be added to the program itself? Will it take a long time?

Thanks for your help and your time,
Blacko

P.S. I'ts my first post here and I'm not to sure about what to do, continue this post or create a new one...

Hey Blacko,
 
> I'm experimenting some issues with the fullscreen mode and the slideshow one.
> They both appear in the bottom-left cornoer of my screen, in a small rectangle,
> like explicated before.

I can't help you with that bug since I cannot reproduce it. Sometimes it's associated with compiz. So try turning it off if you have it turned on and see if fullscreen mode works.

Which version of f-spot do you have? If you have the newest (0.4.2) then the patches posted here are already applied to f-spot and you don't need to apply them yourself. If this is the case you have to wait until f-spot's fullscreen mode is totally bugfree.

Hope that helps!

Hi, 
Yes, if I desactivate Copmiz-Fusion, then it works (fullscreen and sklideshow).

Moreover, I have the 0.4.0 version of F-spot.

I'll try with the lastest version. But it's not available in Ubuntu, I'll have to install it myself (make and ./configure)?

Thank you for your help,
Have a good day, 
Blacko

Blacko: so if this bug is occurring only with Compiz turned on, you may be interested in the Ubuntu bug report about that. This bug may not be due to F-Spot at all, so I'm opening there a task against compiz there too. Thanks for you interest about that.

What do the F-Spot developers think about this? Can it be due to a F-Spot bug that only appear with Compiz?

Thanks for your answer Milan.

Have a nice day,
Blacko

Peter, Blacko

(In reply to comment #27)
> Open a new bug if you still have a problem with a part of this.
> 

but don't discuss any longer on a closed bug