GNOME Bugzilla – Bug 765238
gtktexthandle should avoid connecting to GtkWidget::draw
Last modified: 2016-04-19 19:29:28 UTC
Using ::draw() on the textview causes draw dispatch to hit the slow path (using signal emission). Instead of relying on signals, we should add plumbing to dispatch to the texthandle directly.
(In reply to Christian Hergert from comment #0) > Using ::draw() on the textview causes draw dispatch to hit the slow path > (using signal emission). Maybe I'm missing something, but... We do connect to ::draw on the eventbox we're creating as the text handle (We should probably have an internal widget impl for this though). Nowadays text handles are "popovers" (as seen by GtkWindows), so their drawing is dispatched right from gtk_window_draw(). Is this something you've seen high in profiles?
Forgot to reference the code: https://git.gnome.org/browse/gtk+/tree/gtk/gtktexthandle.c#n288
What I did was add a g_print() for the fallback case in gtk_widget_draw_internal(). What I noticed was that after touching the textview that we immediately, and forever more, hit the fallback path not only for the GtkEventBox, but also the GtkTextView too. That made the scrolling case even more choppy. (We still have probably ~5 more things to optimize to get scrolling back into good shape on larger framebuffer sizes, but this is just one of the items I saw). Everything helps. Being that it's via signal emission, its really hard to quantify the exact offender other than by "feel". Still working on a more scientific way to progress on that front. One way to do so might be similar to my GdkFrameClock patches yesterday, that would introduce an intermediate function for the fallback case which would show up in profiles (and therefore get some counts/cost associated with it).
it is actually the magnifier that connects to ::draw, and never lets go of it again