GNOME Bugzilla – Bug 754658
GtkTreeView should always use RGB (no-alpha) when drawing to pixel cache
Last modified: 2018-04-15 00:39:21 UTC
Created attachment 310778 [details] [review] manually set CAIRO_CONTENT_COLOR for GtkTextView pixel cache I noticed that GtkPixelCache is creating surfaces with cairo_content_t of CAIRO_CONTENT_COLOR_ALPHA. This is not ideal as it means we have to use the composite blending when drawing the pixelcache surface during GtkTextView::draw(). Setting this manually to CAIRO_CONTENT_COLOR should speed us up just a bit more by utilizing cairo/pixman fast paths (also faster in Quartz).
This is not right. We used to correctly pick this up from a solid GdkWindow, and we definitely *do* want to use RGBA in some circumstances. We just have to un-break the auto-picking of content type.
I have patches for Company's suggestion on IRC, to use gtk_style_context_is_background_opaque(). I'll clean them up today.
Created attachment 310933 [details] [review] add _gtk_style_context_is_background_opaque() This adds the style context helper we need to determine if a background is opaque.
Created attachment 310934 [details] [review] if stylecontext has opaque background, use CAIRO_CONTENT_COLOR This fixes the fast path in GtkPixelCache to check if the background is opaque using the new helper.
Created attachment 310935 [details] [review] give pixelcache access to textview's style context This shares the stylecontext from the textview with the pixelcache.
Created attachment 310937 [details] [review] viewport: share style context with the pixel cache Same treatment for GtkViewport
Created attachment 310941 [details] [review] textview: give pixelcache access to style context Updated patch for textview.
So I ran into a bit of an issue doing this for GtkTreeView. It things the base style context is opaque due to the wrong class settings (i think) when the surface is created. This means that we are creating an RGB instead of an RGBA and getting a "black background" for the default, empty case. I need to look into it more, as it would be nice to avoid RGBA in treeview too.
Review of attachment 310933 [details] [review]: ack
Review of attachment 310934 [details] [review]: ack
Review of attachment 310937 [details] [review]: otherwise looks ok. ::: gtk/gtkviewport.c @@ +283,1 @@ gtk_style_context_add_class (gtk_widget_get_style_context (GTK_WIDGET (viewport)), GTK_STYLE_CLASS_FRAME); This could be made to use the new local style_context variable.
Review of attachment 310941 [details] [review]: ack
(In reply to Christian Hergert from comment #8) > It things the base style context is opaque due to the wrong class settings > (i think) when the surface is created. This means that we are creating an > RGB instead of an RGBA and getting a "black background" for the default, > empty case. We're re-checking the style context every time we draw though and potentially creating a new surface. So, the class settings at pixel cache creation time should not matter. Maybe its calling pixel_cache_draw with some weird temporary state on the style context?
retitle for whats left
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