I can not see this on master with my Linux VM, not very fast but OK. Added a couple of print statements to gnc_html.c, line 106 in the scroll vis call back and one at 410 in gnc_html_reload.

As the changes in master are based on maint, it was convenient to use as this should be the same.

With a default style sheet and multicolumn report with two charts side by side set to 600 wide by 500 high in its own window I was able to drag the corner to reveal scroll bars and hide them and all I got in the terminal were half a dozen print statements with no flickering.

Not sure what's going on, I will reboot my PC into Windows 10 and see there.

OK I see it on my windows 10 machine, something to work on...

Created attachment 344581 [details] [review]
Report flicker patch

This patch fixes the flicker with reports on my Windows 10 machine and still works on my Linux VM.

I have no idea why it is different for the two but it seemed to be re-showing the scrollbars on every reload but on my Linux VM it did not appear to be. I have introduced a delay in the reload and stopped any reloads prior to one being completed.

Have a look and see if this fixes the issue you see.

Bob

Bob, thanks for looking into this. I don't think adding a timer will do it. This delay is rather arbitrary. Depending on the speed of the computer and the complexity of the report it may take longer to render a report and you will still get multiple reload requests interfering with one another.

The more I look at this the more I believe we're completely on the wrong track.

For comparison I have been looking at the source code for the midori webbrowser, which is also gtkwebkit based. I've reduced the source code in that project to it's absolute minimum, namely a GtkWindow with one GtkVBox in it. The vbox contains one text entry to add an url, and one GtkScrolledWindow that includes a WebkitWebView. There's only one signal attached: when the text entry is activated, the text is passed to the webkit view to load as an url.

This extremely simple browser manages to resize a report saved to html with no major problems (1), where we're having all kinds of issues in gnucash.

(1) There is still the minor issue that the presence of the vertical scroll bar pushes the legend over the chart. Reloading the chart solves this though.


Important to observe is the simple browser doesn't need any special tricks to 
a. load the chart on 100% width/height
b. make the chart resize when the window resizes
c. handle scroll bars changing visibility

So I think we should remove all the special code we added to maint and start over. There must be something else going on.

I did some experiments already on master where I have disabled
1. the callbacks on scrollbar "show"
2. the callback on expose-event (in gnc-plugin-page-report.c)

With these changes our charts stop dynamically resizing. However several reports suggest webkit does know the proper width of the window. For example try and print an invoice. The address table will stick to the right end of the window (it's marked as right-aligned). And this block will follow even when resizing the window.

Together with the fact that the simple browser just works without any additional quirks, I believe we should continue to investigate why this isn't working in gnucash.

This can be done on master though. As maint only supports fixed width displaying of charts we should revert the chart displaying modifications there (not the option parsing compatibility code) and continue this on master.

Avenues to investigate is temporarily add code to inspect the generated dom tree. Perhaps jqplot is reverting to fixed widths internally for some as yet unknown reason. Or add debug information to show whether or not the resize javascript method gets triggered or not.

Created attachment 344725 [details]
Minimal application with webkit view widget

This tar file contains a a directory called gnucash_webkit_demo with a minimal c project using the webkit library.

To build it do this:
- download and untar the file
- cd gnucash_webkit_demo
- mkdir _build && cd _build
- cmake -DCMAKE_INSTALL_PREFIX=../_inst -G Ninja ..
(you may need to install a few extra dependencies for this)
- ninja-build
- ninja-build install
- ../_inst/bin/midori
(the name is still midori, after the project I took this from...)

As I have been exploring this area for the last two days, I had all the pieces
in place to do the revert. So I have just pushed the necessary changes.

Note that before the report resizing options were added there was a callback on
expose-event in gnc_plugin_page_report.c. I believe this was the wrong signal
even before the resizing option patches were added. So I have also changed
this now to trigger on the report plugin page's "selected" signal instead.

Review of attachment 344581 [details] [review]:

Rejected as motivated in comment 4

I've created bug 778042 as a reminder of what should be investigated on the current master branch.

I am seeing fast flickering if a report tab content is wider than the window, so I guess I am running into the same bug.

Another workaround for me: Select a different tab, then after some seconds go back to the original tab.

I see that you committed a fix at https://github.com/Gnucash/gnucash/commit/02adf447fd245486927f1fa6e8ec9c502d8b0c69 . When do you expect to release GnuCash 2.6.16?

GnuCash 2.6.16 is currently planned for end of March 2017.

The release schedule can be found at http://wiki.gnucash.org/wiki/Release_Schedule

Thanks for sharing your workaround as well by the way.

*** Bug 778560 has been marked as a duplicate of this bug. ***

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=777875. Please update any external references or bookmarks.