this is just an optimization, doesn't have to be on the blocker list.

Created attachment 253042 [details] [review]
textview: implement use of gtkpixelcache for textview.

This patch does a basic implementation of pixelcache for textview.

One piece of magic that should be considered is the amount of extra space we render. I just allocation->height/2 as a basic choice.

Created attachment 253043 [details] [review]
textview: use pixelcache to indirectly renderer to widget.

Fix horizontal scrolling.

Comment on attachment 253043 [details] [review]
textview: use pixelcache to indirectly renderer to widget.

Attachment 253043 [details] pushed as d96882b - textview: use pixelcache to indirectly renderer to widget.

I pushed this with some other fixes. 

On think i didn't understand though is the need for _gtk_pixel_cache_set_content() though. Either we set a non-alpha BG as window background, and then it would have picked color + alpha anyway, or we *do* set a solid opaque bg color on the window, and then GtkWidget will fill that color in _gtk_widget_draw_windows() during draw and then any alpha content is useless.

Why do you always need to use color + alpha? It seems like it will only slow things down.

(In reply to comment #5)
> On think i didn't understand though is the need for
> _gtk_pixel_cache_set_content() though. Either we set a non-alpha BG as window
> background, and then it would have picked color + alpha anyway, or we *do* set
> a solid opaque bg color on the window, and then GtkWidget will fill that color
> in _gtk_widget_draw_windows() during draw and then any alpha content is
> useless. 
> Why do you always need to use color + alpha? It seems like it will only slow
> things down.

We discussed this on IRC, but posting here for historical purposes.

The thought was that the gdkwindow could have a static css background and therefore text would always need to be composited upon it. However, it seems that it should actually be invalidated and we can avoid this if we draw the background too.