After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708423 - GtkTextView regression: current line highlighting not working anymore in GtkSourceView
GtkTextView regression: current line highlighting not working anymore in GtkS...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-09-19 22:01 UTC by Sébastien Wilmet
Modified: 2014-01-09 16:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GtkTextView: Fix regression in GtkSourceView drawing (2.07 KB, patch)
2013-10-02 13:17 UTC, Alexander Larsson
committed Details | Review

Description Sébastien Wilmet 2013-09-19 22:01:01 UTC
I think this is another pixelcache regression in GtkTextView.

The current line highlighting (background color) is not working anymore in GtkSourceView/gedit.

The code for painting the line background:
https://git.gnome.org/browse/gtksourceview/tree/gtksourceview/gtksourceview.c#n2353
Comment 1 Sébastien Wilmet 2013-09-29 19:00:14 UTC
By reverting the last GtkTextView pixelcache commit, the current line highlighting works fine.

https://git.gnome.org/browse/gtk+/commit/gtk/gtktextview.c?id=9a45712ad674782841c83a01f810042ab92b60cd
Comment 2 Alexander Larsson 2013-10-02 12:52:52 UTC
The core problem is that the draw() implementation on GtkTextView now renders the background to the text window GdkWindow, which was previously not done (only the bg on the whole widget was rendered).

If this is disabled in gtktextview.c:draw_text() then the highlighting works again.

I don't quite remember why this was changed though, will have to look it up.

However, even when it *works* its somehow suboptimal for GtkSourceView to be drawing directly to the window when the textview is using a pixel cache. Ideally we'd want the sourceview to piggyback its rendering to the pixelcache too...
Comment 3 Alexander Larsson 2013-10-02 13:17:48 UTC
Created attachment 256260 [details] [review]
GtkTextView: Fix regression in GtkSourceView drawing

GtkSourceView draws before chaining upo to GtkTextView and assumes
that this will be visible, but the pixelcache will just overdraw
that with background.

So, we stop drawing the background to the pixel cache and instead
make it an CAIRO_CONTENT_COLOR_ALPHA surface to make the previously
drawn content see through.

This is slower, but more backwards compatible.
Comment 4 Alexander Larsson 2013-10-02 14:24:05 UTC
Comment on attachment 256260 [details] [review]
GtkTextView: Fix regression in GtkSourceView drawing

Attachment 256260 [details] pushed as 1ac1343 - GtkTextView: Fix regression in GtkSourceView drawing
Comment 5 Alexander Larsson 2013-10-02 14:27:28 UTC
I pushed this fix to 3.10 and master. It *does* make scrolling slower though, so i think for 3.12 we should revert that and instead have new draw vfuncs in GtkTextView that GtkSourceView 3.12 could use to draw before and after the main text rendering but on the pixelcache.
Comment 6 Paolo Borelli 2013-10-02 14:54:24 UTC
Or we could move current-line highlighting in textview.

We know that what GtkSourceView does is a hack... we are more than open to do it in a better way if possible.
Comment 7 Sébastien Wilmet 2013-12-24 13:11:31 UTC
I think we can close this bug, as the current line highlighting works again in GtkSourceView. I've opened the bug #721012 for moving the current-line highlighting in GtkTextView, to have a cleaner implementation, and be able to draw directly to the pixel cache.
Comment 8 Alexander Larsson 2014-01-09 16:37:59 UTC
The fix for this caused a regression in rgba AA rendering as per bug 715008. I've added patches there that solves the problem in this bug in a different way.