Right, I've just looked into this with xournal 0.4.2.1-1fremantle20 and I think
I know the problem.

First a bit of background...

Previously (W41):
To get a nice smooth transition, we do the flipping animation, and end up with
a black screen. Then, while it is black we use xrandr to resize the screen, and
we have to wait for windows to redraw in the new shape before we can do the
second flip back to portrait mode... so we're stuck with a black screen for
ages.

Now (W42):
We take a screenshot of what is on the screen, *then* tell windows to resize
and do the flip animation to black using the screenshot. While it is black we
do the xrandr rotate (but no windows are usually resized here), wait a little
for windows to draw, and then do the flip to portrait.

What is happening for you is nothing is redrawing during the first half of the
'flip' animation, and it's only happening when xrandr resizes the screen
halfway through (and then there's not enough time for it to happen while the
screen is black). 

You can edit [rotate]duration_in/out in
/usr/share/hildon-desktop/transitions.ini and make them longer, then use
xresponse on xournal to check if it is resizing/drawing at the right time.

So my guess is that somehow xournal isn't listening to the GdkScreen
size-changed signal and is determining its orientation some other way? To be
honest I'm not sure quite how - do you just wait until your window has been
forced to resize or do you check directly in some way? Obviously if you're
waiting it seems like there may be some bug, as app windows should have been
resized correctly along with the GdkScreen - and we should look into that.

Also I noticed that you appear to draw the ruled paper directly onto the
window. Because the window is composited, every update could trigger a redraw.
If you could double buffer what you draw, it would make the window appear a lot
more quickly (not just for rotation, but when starting the application too).

That is really interesting.
I will have a look at it tonight.

I think I am only listening at expose events...

We'll check.

Thanks.

I get the same effect with Conboy too and I'm listening for the GdkScreen
size-changed signal to change the UI layout.

Comment 4 Andre Klapper 2009-11-17 13:34:29 UTC

So this is triggered by bug 5825? If so, feel free to add a dependency.

I don't think it depends on that Andre.

This is a temporary screenshot of the running application aimed at speeding up
the rotation, rather than the startup.

The startup screenshot is stored on the disk, while this is temporary and only
used to in the rotate animation.

Aniello

I will work on listening to GdkScreen size changes and see if the issue is
still there (as it seems after reading Comment #3).

If that solves it, than this is a program issue rather than platform issue and
we may close it as INVALID.

Aniello

I'd say this isn't related to 5825 either... The only similarity is the word
'screenshot' used in a comment :)

Comment 8 Andre Klapper 2009-11-17 14:18:47 UTC

Yeah, I should have read this a bit more careful. :-)
Okay, let's wait for results as per comment 6.
--> moreinfo

Well, here is what I´m doing:

g_signal_connect(screen, "size-changed", G_CALLBACK(on_orientation_changed),
window_data);

where screen is GdkScreen*.

the callback itself looks like this:

static
void on_orientation_changed(GdkScreen *screen, SearchWindowData *data)
{
    GtkTreeViewColumn *column;
    GtkWidget *hbox;
    AppData *app_data = app_data_get();

    column = data->change_date_column;
    hbox = data->hbox;

    app_data->portrait = is_portrait_mode();

    if (app_data->portrait) {
        gtk_tree_view_column_set_visible(column, FALSE);
        gtk_widget_hide(hbox);
    } else {
        gtk_tree_view_column_set_visible(column, TRUE);
        gtk_widget_show(hbox);
    }
}

I get the same effect as Aniello. Install Conboy from "maemo.org Extras" to see
this in action. The Phone app is rotating fine, so I guess, they are doing
something different.

After reading Comment #9 above, I don't see why Xournal would behave
differently.
From what I see when rotating, the application gets redrawn AFTER the rotation
has completed (i.e. they are completing the SECOND part of the roation with the
original orientation screenshot).
So I see this:

System takes screenshot in Landscape, start rotation effect using screenshot,
blank (where magic should happen), rotate, blank, continue rotation effect WITH
SAME SCREENSHOT as before, redraw window.

I will try changing the transitions.ini and put longer times and print some
debug info in Xournal so that I know exactly WHEN I get the size changed
signal.

Aniello

(In reply to comment #10)
> System takes screenshot in Landscape, start rotation effect using screenshot,
> blank (where magic should happen), rotate, blank, continue rotation effect WITH
> SAME SCREENSHOT as before, redraw window.

I can guarantee you this is not the case :)
What is drawn for the second half is infact a 'live' image of the current
window. If you slow the animation down you can see the window being redrawn
while it is rotating.

Unfortunately GTK is amazingly slow at redrawing on the device - especially
when there is load from the animation - so even though the redrawing starts on
resize, there will be a big pause before it finishes.

I've come up with a really simple test app that exhibits the problem (even if
no visibility is changed). We should be able to fix this properly in
hildon-desktop.

That's great news. Thanks...

How come Phone app does not exhibit this issue?
Proper way of doing an app? :)

Anyway..thanks, I'll also look at the double buffering issue you've noted in my
app.

aniello

We think we've found the problem... It's some so-called 'performance
improvement' introduced at the last minute and added without anyone asking us
:(

Please can you type "stop ohmd" in the console as an su, and then try?

Definitely on the images I have (I'm using something a bit newer than W42) it
works perfectly after you type that.

(In reply to comment #14)
> Please can you type "stop ohmd" in the console as an su, and then try?

Yup, here after "stop ohmd" rotation is smooth again.

I confirm that as well. Smooth again after stopping omhd.
(not as smooth as 41-10, but smooth, I can better see now the difference you
have introduced in 42-11)

SO what's this ohmd and what should we do now?
Wait for a fix?

Yes, it's not your problem at all. I'll try and make sure this is fixed soon.

Frankly this is so stupid I'm dumbfounded. It went in right before the release,
we were not told about it, and we had no chance to test it or point out the
obvious problem with it.

On rotation, all processes apart from those whitelisted are paused by ohmd - so
it's hardly surprising that if you're not in the whitelist your rotation is
going to be broken.

wrt the rotation speed - this has improved significantly lately and will be in
the next full release. While the initial part of rotation is a bit more jerky,
it does mean the device spends a lot less time with a black screen - which is
what people were complaining about.

I'm tempted to put a "stop ohmd" in my postinst script :)
It's clearly useless now.

Yes, I would. Unless it does something else, because IMO it serves no useful
purpose during rotation whatsoever :)

Comment 21 Andre Klapper 2009-11-17 17:37:03 UTC

Gordon: For future reference, setting an int-xxxxxx alias here is welcome - see
http://wiki.maemo.org/Bugs:Cloning .  :-)
Thanks a lot for importing.

Comment 22 Lassi Syrjälä 2009-11-18 10:08:00 UTC

(In reply to comment #19)
> I'm tempted to put a "stop ohmd" in my postinst script :)
> It's clearly useless now.

Ohmd is a policy daemon. Stopping it, you'd partially or completely cripple at
least Phone, Media player, Camera, and Flash, so that's definitely not the way
to go.

Package policy-settings-rx51 might give some insights into what ohmd does as
well as how you _could_ whitelist your app. That said, I don't think directly
modifying the settings from your postint scripts is the right thing to do
either. There should (and AFAIK, will) be a cleaner, documented way to
integrate with the policy.

Yes, sorry, I've just used bad wording.
I've asked in maemo-developers about what OHM does already and got an answer.
I felt already it was not a good idea to disable it in my postinst file.
If OHM only purpose was to speed up rotation, it could have made sense, but it
does much more than that, so of course I won't touch it.

For now I'll leave things as they are and hope things will be fixed asap. The
ones that will get bad reputation will be us, third party developers ;)

Aniello

Comment 24 Andre Klapper 2009-11-24 14:21:17 UTC

This has been fixed in the internal build version
2.2009.47-23
(Note that 2009 is the year and the number after is the week.)

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

Verifying that rotation is smooth again in 2.2009.51-1.

GStreamer playback still has a very, very short hick-up (you can test this with
Panucci, for example), but window UI relayouting happens instantly "behind the
scenes" during rotation (tested with Panucci and gPodder).

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

Comment 27 Andre Klapper 2010-01-14 12:29:01 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

I can confirm that this bug is FIXED!   Get the latest Firmware update (PR1.1)
and theird party applications are glitch free during auto rotation!!!

(In reply to comment #27)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
> Please leave a comment if the problem is not fixed for you in this update
> version.
> 

Thanks. Works very well and the work done has had a side-effect, thrid party
media players play more constantly like the builtin media player. Before, if I
did any multi-tasking what so ever, the audio would mute for seconds.

Thanks to whoever fixed this.

I am going to speak with respect to audio stuttering that is induced by
external stimulus. More specifically, the top power button or rotation of the
screen (e.g., in the browser) causing a pause in my music playing in the
mediaplayer. 

I have an up-to-date n900. I ran "stop ohmd" to test if it got rid of my audio
pausing, and it did.

So ohmd still has some issues with regards to its stopping policies.

Comment 31 Andre Klapper 2010-10-13 09:49:52 UTC

(In reply to comment #30)
> I am going to speak with respect to audio stuttering

Audio is unrelated to this bug report which is about rotation.