GNOME Bugzilla – Bug 658092
St ::hover transitions don't act as expected
Last modified: 2012-04-25 21:48:23 UTC
This is easier with St.set_slow_down_factor(5) Steps: 1. Enter overview. 2. Focus search field by clicking on it. 3. Click to the left to defocus it. 4. While the search field is fading out, move over to the left and hover over the items in the dash. Expected: The search field continues to fade out, and the dash items fade it. Actual: The search field turns to its fully focused state until the transition time finishes, then the dash turns to its fully hover state.
Created attachment 195952 [details] Test for multiple multitexture materials This appears to be a Cogl (or GL driver) bug. Raw Cogl test attached. If you comment out: draw_material (mat2, 0, -1, alpha); the crossfade works correctly. For those lazy enough to edit the source with their own image filenames: $ wget http://magcius.mecheye.net/random/Craig.jpg $ wget http://git.gnome.org/browse/cogl/plain/examples/crate.jpg
hi, I replied on irc before realizing you said you were going to sleep :-) here's the log: (01:11:04 PM) rib_away: magcius: it's very likely your gpu only supports to layers of multi-texturing. damien recently added experimental api for use in clutter-gst for being able to explicitly query the number of texture units that can be used for fragment processing: cogl_renderer_get_n_fragment_texture_units() (01:11:21 PM) rib_away: *two layers.. (01:17:47 PM) rib_away: magcius: well maybe I shouldn't say "very likely" I have no idea what your gpu is, though there are quite a few gpus with only limited multi-texturing capabilities so it could be worth checking with cogl_renderer_get_n_fragment_texture_units() to see if that's the problem. (01:18:43 PM) rib_away: magcius: if it is then it would be good if Cogl at least would print a nice warning if you try and do multi-texturing with more layers than the hardware supports (01:23:25 PM) rib_away: magcius: : to get the underlying CoglRenderer from a context - since you aren't create it explicitly - you can use cogl_context_get_display() followed by cogl_display_get_renderer(). The renderer conceptually is an object representing your gpu so that's the api to use for querying its capabilities. (01:30:41 PM) rib_away: doh! I only just saw that magcius wen't to sleep :-)
Created attachment 196039 [details] [review] tests: Add transition test Just a simple test before I had the raw Cogl test.
Created attachment 196043 [details] [review] arbfp: track which layers have combine constants Ok I think I've figure it out... We weren't actually tracking which layers have been allocated param space for combine constants; all layers just had a default constant_id of 0 that indexes into the program.local[] params array and a dirty flag to say when the constant needs updating. There are times though when we say to update everything by-passing the dirty flag and because we weren't actually tracking which layers needed constants we would always write a constant to program.local[0] for every layer. The upshot was that we could end up clobbering a real constant that was actually allocated the constant_id = 0 slot. This patch adds a new UnitState bitfield to track if the layer has a corresponding constant that may need flushing and we only ever write the constant with glProgramLocalParameter4fv if that's set. I'll hopefully land this patch in master tomorrow once I can get Neil to review it. It'd be good to hear if this fixes the problem for you too.
(In reply to comment #4) > Created an attachment (id=196043) [details] [review] > arbfp: track which layers have combine constants > > Ok I think I've figure it out... > > We weren't actually tracking which layers have been allocated param > space for combine constants; all layers just had a default constant_id > of 0 that indexes into the program.local[] params array and a dirty flag > to say when the constant needs updating. There are times though when we > say to update everything by-passing the dirty flag and because we > weren't actually tracking which layers needed constants we would always > write a constant to program.local[0] for every layer. The upshot was > that we could end up clobbering a real constant that was actually > allocated the constant_id = 0 slot. > > This patch adds a new UnitState bitfield to track if the layer has a > corresponding constant that may need flushing and we only ever write the > constant with glProgramLocalParameter4fv if that's set. > > I'll hopefully land this patch in master tomorrow once I can get Neil > to review it. It'd be good to hear if this fixes the problem for you > too. Works beautifully for me and makes the Shell dash experience 10 times better.
Created attachment 196052 [details] [review] tests: Add transition test Another more "permanent" test -- after the Cogl fix, there are a few more issues that need to be investigated, but nothing too major. Issues: Mouse over the stage, mouse over a node, let it fade to green all the way, then quickly mouse out of the window and back in.
Comment on attachment 196043 [details] [review] arbfp: track which layers have combine constants http://git.gnome.org/browse/cogl/commit/?id=b6cea6bed6e51e59322e9f9398c9d1810a147563
Comment on attachment 196052 [details] [review] tests: Add transition test Attachment 196052 [details] pushed as 523e431 - tests: Add transition test Adding the transition tests...