Bug 6203 (int-147061)

Summary: Rotation in 42-11 is not as smooth as in 41-10 for some third party apps
Product: [Maemo Official Platform] Desktop platform Reporter: Aniello Del Sorbo <anidel>
Component: window-managerAssignee: Tapani Pälli <tapani.palli>
Status: VERIFIED FIXED QA Contact: window-manager-bugs
Severity: critical    
Priority: Low CC: andrea, andre_klapper, chad, christian, david, eero.tamminen, gordon.williams, hald, jukey, lassi.syrjala, m, martin, svisvanatha, talhajj
Version: 5.0/(1.2009.42-11)   
Target Milestone: 5.0/(2.2009.51-1)   
Hardware: N900   
OS: Linux   
Bug Depends on:    
Bug Blocks: 7087    

Description Aniello Del Sorbo (reporter) 2009-11-16 00:59:45 UTC
SOFTWARE VERSION:
1.2009.42-11

STEPS TO REPRODUCE THE PROBLEM:
Install Xournal, launch it, rotate the screen

EXPECTED OUTCOME:
Xournal should rotate smoothly
Check: http://www.youtube.com/watch?v=qnlvMOy-HOs

ACTUAL OUTCOME:
Xournal does not rotate smoothly
Check: http://www.youtube.com/watch?v=Am4OPfI1xUo

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
Not sure this is the right component to file this bug.
Yerga StockThis seems to suffer the same issue.
Comment 1 Gordon Williams 2009-11-16 15:37:46 UTC
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).
Comment 2 Aniello Del Sorbo (reporter) 2009-11-16 16:03:07 UTC
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.
Comment 3 Cornelius Hald 2009-11-16 20:41:01 UTC
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 maemo.org 2009-11-17 13:34:29 UTC
So this is triggered by bug 5825? If so, feel free to add a dependency.
Comment 5 Aniello Del Sorbo (reporter) 2009-11-17 13:49:08 UTC
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
Comment 6 Aniello Del Sorbo (reporter) 2009-11-17 13:50:38 UTC
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
Comment 7 Gordon Williams 2009-11-17 14:14:55 UTC
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 maemo.org 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
Comment 9 Cornelius Hald 2009-11-17 14:29:04 UTC
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.
Comment 10 Aniello Del Sorbo (reporter) 2009-11-17 14:46:31 UTC
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
Comment 11 Gordon Williams 2009-11-17 15:11:45 UTC
(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.
Comment 12 Gordon Williams 2009-11-17 15:20:03 UTC
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.
Comment 13 Aniello Del Sorbo (reporter) 2009-11-17 16:16:37 UTC
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
Comment 14 Gordon Williams 2009-11-17 16:41:45 UTC
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.
Comment 15 Cornelius Hald 2009-11-17 16:45:29 UTC
(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.
Comment 16 Aniello Del Sorbo (reporter) 2009-11-17 16:50:15 UTC
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)
Comment 17 Aniello Del Sorbo (reporter) 2009-11-17 16:51:14 UTC
SO what's this ohmd and what should we do now?
Wait for a fix?
Comment 18 Gordon Williams 2009-11-17 17:16:20 UTC
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.
Comment 19 Aniello Del Sorbo (reporter) 2009-11-17 17:30:07 UTC
I'm tempted to put a "stop ohmd" in my postinst script :)
It's clearly useless now.
Comment 20 Gordon Williams 2009-11-17 17:32:26 UTC
Yes, I would. Unless it does something else, because IMO it serves no useful
purpose during rotation whatsoever :)
Comment 21 Andre Klapper maemo.org 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ä nokia 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.
Comment 23 Aniello Del Sorbo (reporter) 2009-11-18 13:20:02 UTC
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 maemo.org 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.
Comment 25 Thomas Perl 2009-12-23 17:37:51 UTC
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).
Comment 26 Daniel Martin Yerga 2010-01-10 13:34:39 UTC
*** Bug 7777 has been marked as a duplicate of this bug. ***
Comment 27 Andre Klapper maemo.org 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.
Comment 28 Chad Diederichs 2010-01-14 18:55:34 UTC
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!!!
Comment 29 David Ward 2010-01-15 01:44:06 UTC
(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.
Comment 30 Tarek Alhajj 2010-10-13 06:54:38 UTC
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 maemo.org 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.