GNOME Bugzilla – Bug 721597
Visual errors when row is inserted in fixed height mode
Last modified: 2018-04-15 00:39:00 UTC
Created attachment 265389 [details] Interactive test case The attached testcase demonstrates the problem. It seems to only occur in Gtk+-3 and only in fixed height mode. The testcase presents an empty treeview window 2 rows high, with an 'add row' button. Each row is added above the previous row, the row values are decreasing integers starting from 9. After 2 rows have been added the visible area begins to display rows in the wrong place or the bottom row becomes completely blank. Mousing over a row makes it display correctly again. The exact nature of the artifacts varies depending on which Gtk version I use; with Git master, I see: - '9' in both rows on the 3rd 'add row' press - bottom row goes blank on the 5th 'add row' press - '9' is displayed in both rows on 7th 'add row' press and all subsequent ones
Created attachment 266324 [details] [review] multiqueue: prevent buffering forever with playbin When prerolling/buffering, multiqueue has its buffers limit set to 0, this means it can take an infinite amount of buffers. When prerolling/buffering finishes, its limit is set back to 5, but only if the current level is lower than 5. It should (almost) never be and this will cause prerolling/buffering to need to wait to reach the hard bytes and time limits, which are much higher. This can lead to a very long startup time. This patch fixes this by setting the single queues to the max(current, new_value) instead of simply ignoring the new value and letting it as infinite(0)
Created attachment 266325 [details] [review] multiqueue: prevent buffering forever with playbin When prerolling/buffering, multiqueue has its buffers limit set to 0, this means it can take an infinite amount of buffers. When prerolling/buffering finishes, its limit is set back to 5, but only if the current level is lower than 5. It should (almost) never be and this will cause prerolling/buffering to need to wait to reach the hard bytes and time limits, which are much higher. This can lead to a very long startup time. This patch fixes this by setting the single queues to the max(current, new_value) instead of simply ignoring the new value and letting it as infinite(0)
Comment on attachment 266325 [details] [review] multiqueue: prevent buffering forever with playbin Sorry, attached to the wrong bug :(
Created attachment 267765 [details] [review] treeview: Fix visual glitch on row-inserted With fixed row height, when rows are inserted but not visible there's a call to queue_resize_no_redraw() to avoid useless redraw operation. However, when calling gtk_tree_view_top_row_to_dy() to adjust the adjustment/scroll position, a redraw would be performed leading to some invalid visual "glitches" (e.g. rows moved to wrong place). Disabling this when called from gtk_tree_view_top_row_to_dy() avoids such issues.
This fixes the issue for me against Gtk+ master. Thanks for the patch!
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new