#1567 Display is flashing when scrolling with Gtk+ 3

Bug
closed-fixed
nobody
5
2014-05-22
2014-01-05
No

The way drawing is handled has changed between Gtk+ 2 and Gtk+ 3. Scintilla is good with Gtk+ 2 but quite bad using Gtk+ 3.

One annoying point is the display flashing when the window is redrawn. It's especially annoying when moving in the text using the cursor keys.

Related

Bugs: #1625
Bugs: #1681

Discussion

<< < 1 2 (Page 2 of 2)
  • Colomban Wendling

    I still don't get the initial draw in Geany with this (GTK 3.8).

     
    Last edit: Colomban Wendling 2014-02-17
    • Colomban Wendling

      OK, I just tried gtk3_avoid_flickering_2.patch with a compositing WM (mutter), and it worked. So I guess it's the difference between your tests and ours, you using a compositing WM that caches all draws in textures, and us using a non-compositing WM and then need draws when the X server wants them.

      Maybe your could try on your side with a non-compositing WM?

       
      Last edit: Colomban Wendling 2014-02-17
      • Sébastien Granjoux

        I have tried with a virtual machine using Mint 16 but indeed the virtual machine is run in a compositing WM so it could explain the difference.

        I will try without a compositing WM but not before next week.

         
    • Colomban Wendling

      OK, my distro updated from 3.8 to 3.10.7 and with this version your patches seem to work OK.

       
      Last edit: Colomban Wendling 2014-02-17
    • Colomban Wendling

      Ah, and now I have GTK 3.10.7, I do see some flickering without the patch, with and without a compositing WM (tho I see it most without).

      I'll check a bit more in the upcoming days.

       
      Last edit: Colomban Wendling 2014-02-17
  • Sébastien Granjoux

    That's fine for me. I can keep this patch in Anjuta tree anyway.

    I still don't know why I don't see the issue here.

     
    • Neil Hodgson

      Neil Hodgson - 2014-02-14

      The most likely reason for the different results appears to me to be a version skew somewhere in libraries, window managers, or theme. Possibly display driver issues.

      Since there are different results, there may be more people experiencing the reported problem or who will experience it in the future as GTK+ 3 becomes more common. It may be worthwhile including a version of your change in the main repository with an #if around it. That would make it easier for you (or others) to track Scintilla changing. If others report similar issues to you then we can suggest turning on the #if.

       
  • Nils Nordman

    Nils Nordman - 2014-04-22

    I just crashed into this today, after upgrading to Ubuntu 14.04. Previous Gtk+-3 version as shipped with 13.10 was fine, but with the latest (3.10.8) it's all flickering all over the place. Applying "check_on_gtk_3_8.patch" removed the flickering here. I haven't tried the patch with any older version to see whether it works fine there as well though.

     
  • Nils Nordman

    Nils Nordman - 2014-04-22

    Some more data points: Problem is the same in latest Arch (Gtk 3.10*), and the last patch fixes it there as well as could be expected. Also tried the patch out on an old 11.10 release of Ubuntu (Gtk 3.2.0), and it worked fine for me, I didn't see anything amiss during my testing. I'll carry the patch in-tree for now (Thanks Sébastien!), but I would definitely like to see it or a version thereof in Scintilla. Even though the issue summary describes it as being an annoyance, it seems a show-stopper to me. The flickering is so bad as to make my editor unusable, at least on my system.

     
  • Colomban Wendling

    @nilnor although the "check_on_gtk_3_8" patch somewhat lowers the visiblity of the issue (why, really not sure), it does NOT fix it. Also, apparently compositing WMs lower (or nullify) the visibility of the issues, so please also try disabling the compositing.

    But I agree with you, this is not simply "annoying", it pretty much renders Scintilla unusable on GTK3, because all this flickering kills the eyes in no time. Fortunately we (Geany) still have support for GTK2, so I went temporarily back to using the GTK2 version before finding a real solution for this problem. Now I have some time, I'll try to sum up problems and possible solutions in a mail to the ML in the next days.

     
  • Colomban Wendling

    Proposed patch to fix the issue. It is kind of ugly as it extends the clip manually, but it allows to perform the whole draw in one single shot, avoiding any flickering possibility. It also uses the container draw propagation from one of the patches here, as required to avoid the normal, non-re-scheduling, case.

    As noted in the patch header, this should be better tested on older GTK3 to add or remove version checks. I guess they could be removed, but testing is better than guessing.

     
  • Neil Hodgson

    Neil Hodgson - 2014-04-22

    There are also drawing problems with GTK+ 2 on Ubuntu 14.04 using it inside VirtualBox. Also seeing some similar bugs in FireFox although not as often.

    Resetting the clip does appear a little strong. It seems that GTK+ has changed to try to optimize drawing and it would be better, if possible, to cooperate with this change.

    Scintilla uses a high priority idle function to perform some work before painting and I am wondering if this is interacting badly with drawing. I may try disabling it.

     
    • Colomban Wendling

      Well, "cooperating" would mean to always paint the whole invalidated area, since now it forcefully clears it (which kind of makes sense from its POV).

      So yes, I agree it would be the best solution, but it may require some deeper changes (or maybe I miss something obvious, I'm not much knowledgeable about Scintilla rendering internals).

      (BTW, I guess that the change in GTK is rather to ease support for in-window popovers than solely optimization, even though it indeed can help)


      And I can imagine we have some small rendering problems on GTK versions that honor the single buffering, as then we can suffer from the classic single-buffering problems, that is that an unfinished paint can reach the display. I'm not sure how the drawing code works for this never to have been an issue, but I guess it could still be visible on sufficiently slow hardware.

       
  • Neil Hodgson

    Neil Hodgson - 2014-05-22
    • labels: --> scintilla, gtk
    • status: open --> closed-fixed
     
<< < 1 2 (Page 2 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks