After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638652 - Tile fade animations stop under GTK3
Tile fade animations stop under GTK3
Status: RESOLVED FIXED
Product: libchamplain
Classification: Core
Component: General
0.9.x
Other Linux
: Normal major
: ---
Assigned To: libchamplain-maint
libchamplain-maint
Depends on:
Blocks:
 
 
Reported: 2011-01-04 12:50 UTC by Jiri Techet
Modified: 2011-03-01 22:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jiri Techet 2011-01-04 12:50:38 UTC
With the latest GTK 3 and clutter built using jhbuild, the fade-in tile animations are not always completed and the tiles remain half-faded or don't appear at all. The tiles are correctly displayed only after subsequent movement of the map by mouse.
Comment 1 Robert Bruce Park 2011-01-05 17:16:24 UTC
I noticed that once all the tiles for a given area are loaded, you can pan around that area without any difficulties (map always updates and displays correctly), it is only during tile loading that the problem exists.
Comment 2 Laurent Bigonville 2011-01-12 19:43:52 UTC
I cannot reproduce this issue when compiling on ubuntu natty

libclutter-1.0-0 1.4.2-0ubuntu2
libclutter-gtk-1.0-0 0.91.4-3
Comment 3 Jiri Techet 2011-01-12 19:50:41 UTC
Great, that's really good to hear. I'll leave the bug open just in case, but if it doesn't re-appear, I'll close it later during the 0.10 release cycle. Thanks for testing it.
Comment 4 Laurent Bigonville 2011-01-13 21:30:05 UTC
I can reproduce now with libclutter-1.0-0 1.5.12-1ubuntu1 that has just been uploaded to natty :/
Comment 5 Jiri Techet 2011-01-19 13:08:11 UTC
I have already installed natty and experience this bug too. 

I'm now working on some interface changes which have higher priority since ABI/API freeze is January 31 (I'm afraid I'll be slightly delayed anyway). I'll look at this bug immediately after I'm done with the interface stuff.
Comment 6 Robert Bruce Park 2011-01-24 02:02:44 UTC
Perhaps I am going crazy, but it seems to me that this bug's symptoms have been significantly reduced in latest git. Perhaps something has been fixed in Clutter that makes this slightly better?

Currently, when libchamplain is initialized, it draws mostly grey with maybe one or two tiles displayed. Then, when I first drag the map by mouse, I get a very jerky map drag, but all tiles begin displaying immediately at drag start. After a second or two, the drag motion smooths itself, and then tiles begin to load normally.

Tile fade animation is still stutterred/choppy, but tiles do successfully fade in during load instead of the previous behavior of simply not appearing until drag action begins. 

Can anybody else confirm that this has gotten slightly better in the last couple days?
Comment 7 Robert Bruce Park 2011-01-28 02:15:49 UTC
I've discovered a (perhaps brutish) workaround for this bug.

I've connected a handler to the "paint" signal of ChamplainView, and in the handler I call ChamplainView.queue_redraw(). 

Works _flawlessly_. All the tiles are forced to draw when they finish loading, and all the other related screen-not-updating bugs have vanished (for example, my app has a color selection widget where you can choose the stroke color on ChamplainPolygons. The handler for the color selection widget is instant-apply, but you wouldn't *see* the color change until you moved the map. This handler allows the user to *see* the instant-apply colors change directly as they are applied. 

Here's the code, super simple:

    def paint_handler(self, map_view):
        map_view.queue_redraw()

    def __init__(self):
        champlain     = GtkChamplain.Embed()
        self.map_view = champlain.get_view()
        self.map_view.connect("paint", self.paint_handler)
Comment 8 Robert Bruce Park 2011-01-28 02:29:38 UTC
Spoke too soon, it seems. I've tested this further and this only updates the display of the first-loaded polygon. Can't quite figure out why that would happen, but there it is. If I have two polygons loaded and I fiddle with my color selection widget, one polygon changes color immediately, and the other one doesn't display it's new color until the map is moved. 

There's another aspect to this bug that I should also mention. I have a custom ClutterActor that animates in front of the map. it's an irregular shape, but as it moves around, the smallest possible square that encompasses it turns solid grey (eg, the tile-not-yet-loaded color). So there can be tiles loaded around this actor but when the actor moves, the portions of the tiles beneath the actor disappear. The workaround I previously posted alleviates this and the actor animates smoothly with the map displaying properly around and behind it, however.
Comment 9 Robert Bruce Park 2011-02-05 04:50:25 UTC
Anybody have any input on this? Why does my workaround work? Does this shed any light on the issue for you, Jiri?
Comment 10 Jiri Techet 2011-02-09 22:33:58 UTC
This is top priority for me now. I've already spent half a day trying to find the problem last weekend but without much success. For testing purposes I'll try to modify VhamplainView so it doesn't use anything else, create dummy tiles and will see if I can track down the problem.
Comment 11 Robert Bruce Park 2011-02-12 01:52:07 UTC
Here's another detail that might help you pin this one down. On my ChamplainMarkers (uh, now ChamplainLabels), I connect to enter-event and leave-event signals. In enter-event, I englarge the size of the Label by 5%, and then leave-event, I shrink it down by 5%. 

With the workaround (from comment #7) disabled, the labels wouldn't change size when I moused over them, UNLESS the display was performing a kinetic animation. That is, if I flicked the map really fast and then moused over a Label while the display was still moving, the Label sizes would change correctly. But once the display stopped moving, the labels stopped responding to mouseover events. The workaround solves this problem nicely, Labels respond to mouseover events again.

So, what I'm getting at here is that I don't think this is actually a bug in the *tile* rendering, so much as it is a bug somewhere in how the actual display is updating *at all*. Somehow, dragging the map seems to force the display to draw (thus rendering tiles and Markers and Polygons correctly), but while the map is not moving, the display rendering is somehow stunted.
Comment 12 Jiri Techet 2011-02-12 19:11:45 UTC
So I hope it's fixed now (I'm not really sure why the change I made fixed this problem, but the world would be much less interesting without mysteries). Please check that it works for you too.
Comment 13 Robert Bruce Park 2011-02-13 02:12:58 UTC
It's certainly better but not quite fixed yet. The problem I described about Label resizing not being visible is fixed, but now dragging the map is quite choppy.

Also, when a custom ClutterActor animates in front of the map, the map draws all grey, and it takes quite a bit of dragging around to bring it back. My workaround from comment #7 is still necessary to keep things running smoothly.
Comment 14 Robert Bruce Park 2011-02-14 17:53:48 UTC
I played around a little bit more with my workaround turned off, and this is what I found:

* Labels seem to be totally fixed. I can drag them, they respond to my mouse-hover-resizing perfectly, everything's great. Also, when I click a photo in my GtkListStore (which results in a selection-changed handler turning the unselected Labels transparent) this change is visible right away. It is no longer necessary to drag the map to get Labels to display properly.

* The path stroke on a MarkerLayer is a different story. If I open the colorchooser that controls the path stroke color and then use the mouse wheel on the 'hue' spinbutton, the color of the path displayed in the map doesn't change until I drag the map view around. With my workaround enabled, the map view updates in realtime and you can watch the path stroke color cycle through the colors of the rainbow automatically.

* I have four ClutterActors that I place in front of the map. One is a ClutterText that displays map center coordinates, and the other three are ClutterRectangles. Two of the rectangles are sized/rotated to form an 'X' at map center. Normally, I animate them in during app startup. They start off larger than the clutter stage, but invisible, and then they shrink+fade into existence.

This animation destroys the map. The map turns dark grey the entire time that this animation is occurring, and then I have to drag the map around a significant distance to make it start drawing the map again (like, I have to make a drag motion that's almost as long as the entire stage). Even then when it starts drawing again, everything is choppy and slow feeling, and then when the ClutterText changes it's value, the area behind it turns dark grey (so the map is visible everywhere except underneath the text). If I disable this animation, the map has no trouble drawing everywhere, including underneath the ClutterText. It's quite strange, the motion of an unrelated ClutterRectangle causes the background behind the ClutterText to fail to render.

If I reduce the initial size of the rectangles so that they fit within the stage initially, the map draws, but still fails to draw behind the ClutterText.
Comment 15 Jiri Techet 2011-02-16 10:18:00 UTC
I spent most of the last Sunday investigating this - without any success. I tried reverting mx to tidy, changing the container structure in libchamplain, changing tile generation, inheriting champlain actors back from ClutterGroup, trying to find a bug in mx and many other things - no real result. I tend to think that there's some bug in clutter or gtk - after all, everything works fine for gtk 2.

I'll release 0.9.0 without this bug fixed as this needs more time but then I'll try to create a minimal example that reproduces it and create a bug report for clutter. Even if it's not a bug in clutter, the clutter people will know much better than me what might be wrong.
Comment 16 Robert Bruce Park 2011-02-17 03:35:32 UTC
Alright, sounds good. Will be good to have a 0.9 release so that I'm not the only person bugtesting this stuff ;-)
Comment 17 Robert Bruce Park 2011-02-18 05:05:28 UTC
I made a couple screencasts, demonstrating libchamplain behavior with and without my workaround from comment 7.

Without the workaround, libchamplain behaves like this:

http://robru.github.com/choppy-no-workaround.ogv

* whole map is grey while X is animating.
* Map coordinates displayed at map top center occaisionally have a dark grey background that they shouldn't.
* All the choppiness that you see is actually apparent in the application, and not just due to video quality (this screencast is much larger than the other one I posted to that other bug, and is a smooth video showing how choppy the application is). There are many instances where you can clearly see the mouse cursor turn into the 'drag' cursor, and I drag the map around, but the map doesn't actually move. 

When I enable the workaround, everything is actually really nice and smooth:

http://robru.github.com/smooth-with-workaround.ogv

* map never goes grey like without the workaround
* map coordinates always display correctly
* there is a little bit of choppiness right at the first drag, but it subsides and then everything gets smooth after. This has been like this since I started using libchamplain back in 0.4, even before this bug started or when I started using the workaround.
Comment 18 Robert Bruce Park 2011-02-18 06:02:46 UTC
Not sure if this is related, but I started using ChamplainScale today, and it looks like this:

http://robru.github.com/Screenshot-GottenGeography-Scale.png

It stays looking that way until the first time that I zoom. After the first zoom, it looks totally fine, but it displays corruptedly like that until at least one zoom action occurs, either in or out.
Comment 19 Robert Bruce Park 2011-02-20 21:40:58 UTC
Ok, http://git.gnome.org/browse/libchamplain/commit/?id=41c78aefe2b256a7b3d22ed09366e07e832e35db this seems to have fixed the ChamplainScale problems. 

However, now when I launch the program the map is frequently corrupted right from the start, and my GPX files won't even load anymore, instead the app hangs in an unusual way.

What happens is that the app doesn't LOOK hung, in fact it's totally responsive to interactions. BUT, the GPX doesn't even start to load, I don't even get to see a single point rendered onto the map. If I try to close the program, I get this error from Gtk:

    (<unknown>:25299): Gtk-CRITICAL **: gtk_main_quit: assertion `main_loops != NULL' failed

(that prints to the terminal once for each time that I click on the X button in the window titlebar).

Then, if I Ctrl+C into the terminal, I get this traceback:

Traceback (most recent call last):
  • File "/home/robru/Applications/gottengeography/gg/app.py", line 702 in add_files_dialog
    self.open_files(chooser.get_filenames())
  • File "/home/robru/Applications/gottengeography/gg/app.py", line 520 in open_files
    self.redraw_interface(i / total, basename(name))
  • File "/home/robru/Applications/gottengeography/gg/app.py", line 833 in redraw_interface
    while Gtk.events_pending(): Gtk.main_iteration()
  • File "/opt/gnome/lib64/python2.7/site-packages/gi/module.py", line 263 in __getattr__
    return getattr(self._introspection_module, name) KeyboardInterrupt


This suggests to me that the app got stuck in the Gtk.events_pending() while loop, and was never able to get out of it. I'm not sure what to make of this. Did you break Gtk.events_pending() so that it always returns true? Did somebody else do this?
Comment 20 Robert Bruce Park 2011-02-21 22:37:06 UTC
I tried reverting all way back to commit c7cd8f7885af572b61ac0e1bd62c18420dd19e2f and that didn't fix this problem I'm having with these infinite loops, so I think it's safe to say that this wasn't caused by anything you changed recently.

I pinged J5 on this, hopefully he'll be able to shed some light on the situation.
Comment 21 Robert Bruce Park 2011-02-23 07:18:14 UTC
Ok, I've tried to boil this down to it's essence, but this alone isn't triggering it:

$ jhbuild run python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gtk
Gtk-Message: Failed to load module "pk-gtk-module"
>>> while Gtk.events_pending(): print 'blah'; Gtk.main_iteration()
... 
blah
True
>>> while Gtk.events_pending(): print 'blah'; Gtk.main_iteration()
... 
>>> 

So, something much more subtle is going on here that I can't even begin to fathom.
Comment 22 Jiri Techet 2011-02-23 23:01:54 UTC
The title of the bug is a bit misleading - it's actually not related to gtk version but to clutter version (1.4 works, 1.6 doesn't). More info here:

http://bugzilla.clutter-project.org/show_bug.cgi?id=2576
Comment 23 Laurent Bigonville 2011-02-23 23:47:04 UTC
GIT head seems to work for me on natty

The *-gtk demos are working fine. the non-gtk demos are crashing with

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  30 (X_GLXChangeDrawableAttributes)
  Serial number of failed request:  62
  Current serial number in output stream:  64

but this looks not like a champlain bug
Comment 24 Jiri Techet 2011-02-26 13:05:39 UTC
It just made an impression it worked fine under Natty - there were a few workarounds to eliminate the visible problems. If you were able to run the animated-marker demo (btw. I get the same error as you), you would see the animations didin't work. Apart from that, the view wasn't repainted when minimized/restored, which was just another aspect of the bug.

OK, maybe you have noticed I used the past tense in the above paragraph - the good news is it is fixed now. I used ordinary clutter operations instead of the low level cogl operations for viewport positioning which fixed the problem with too aggressive clutter clipping.

Please test.
Comment 25 Robert Bruce Park 2011-02-26 23:27:23 UTC
Excellent work, Jiri! I disabled the workaround and things are much better! The stuff about the ClutterText having an opaque background has stopped, ClutterActors can animate in front of the map without issue, etc etc.

There are still some issues with map tile corruption, but in general it's much less bad than it was (I'll post a new screencast shortly).
Comment 26 Robert Bruce Park 2011-02-26 23:52:03 UTC
Hmmm, it seems I am no longer able to navigate the map with the mouse. My keyboard navigation works, and my search box works, but I can't seem to drag the map by mouse, or zoom with the mouse wheel.

It's strange because launcher-gtk works with the mouse, so I don't know where this is going wrong.
Comment 27 Robert Bruce Park 2011-02-27 06:40:19 UTC
Yep, seems like something's broken the mouse in the introspection annotations. Here's the simplest reproducer that allows absolutely no mouse interactions:

$ jhbuild run python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gtk, GObject, GtkClutter, GtkChamplain
Gtk-Message: Failed to load module "pk-gtk-module"
>>> GObject.threads_init()
>>> GtkClutter.init([])
(<enum CLUTTER_INIT_SUCCESS of type ClutterInitError>, [])
>>> window = Gtk.Window()
>>> embed = GtkChamplain.Embed()
>>> window.add(embed)
>>> window.show_all()
>>> Gtk.main()

So, with my application, I can't drag or zoom the map by mouse, and my ChamplainLabels aren't responding to mouse-in/out events, and they're not responding to click or drag events, however there is something quite peculiar going on. Somehow, scrolling the mouse over a ChamplainLabel is triggering the leave-event signal, because I'm able to shrink the labels by scrolling the mouse wheel over them (the signal handler for leave-event scales the ChamplainLabel down by 5% and that is clearly happening).

Here's a screencast for you. Note at first how mousing over the Labels has no effect on them, and then the mouse cursor stays mostly still while the Label under it starts changing size, that's me using the mouse wheel. Then when the view starts moving, that's keyboard navigation. 

http://exolucere.ca/no-mouse.ogv
Comment 28 Jiri Techet 2011-02-27 22:59:26 UTC
I think it's not python-specific - we have the same problem with eog C plugin:

https://bugzilla.gnome.org/show_bug.cgi?id=642802

I've created a corresponding clutter bug report here:

http://bugzilla.clutter-project.org/show_bug.cgi?id=2582
Comment 29 Robert Bruce Park 2011-02-28 01:42:37 UTC
Quite strange, why did this no-mouse bug bite the EOG people 5 days before it bit me? Also, why does scrolling the mouse wheel fire leave-event?

I've tested this a bit further, what's actually happening is that any type of click, be it left, middle, or right button, or scrolling the wheel, all emit both enter-event and leave-event, however scrolling the wheel tends to emit leave-event more often than enter-event, resulting in my Labels shrinking. Clicking keeps them the same size because the two events are paired and cancel each other out. The button-press signal or the dragging signals never fire, and enter/leave-event don't fire for actual mouse hover actions.
Comment 30 Laurent Bigonville 2011-02-28 09:55:06 UTC
I guess that the mouse bug is completely unrelated to the tile animation and a new one should be opened for keeping track of it for the champlain project
Comment 31 Robert Bruce Park 2011-02-28 17:40:18 UTC
Done. https://bugzilla.gnome.org/show_bug.cgi?id=643510

Jiri, can you close this bug?
Comment 32 Jiri Techet 2011-03-01 22:54:55 UTC
Yep, good point, this shouldn't become a collector of all "mysterious" bugs we have. If there are more painting or other problems, new bug reports should be opened for them. Closing.