Code block are misplaced and overlap text

[PierreRust]

When I create a code block on a page , switch to another page and switch back to the original page, the code block is misplaced in the display and overlap the surrounding text.

This does not happen with the first code block on the page, but with every subsequent block.

When clicking on the page, the click seems to happen on the expected position of the items, and not on the rendered display.

This happens on 0.7rc2 (rc1 as well) on linux with kde.

[PierreRust]

I don't understand why, but the problems comes from the ScrolledWindow that contains the GtkSource widget.
When I use add_with_viewport everything works correctly ; it seems that the GtkSource requires a viewport, even though it implements Scrollable and thus should not need it.

I can submit a patch, but it would be better if I could understand why it works that way (might be a bug a Gtk's side).

[jaap-karssenberg]

On my system this doesn't happen, so may depend on the gtk version as well ?

[PierreRust]

I'm using gtk 3.22.30-1ubuntu1, but it's on a kde desktop (in case that could explain anything). What do you have on your system ?
I've tested on another box (with a mate desktop, this gtk based) and I don't have the bug.

BTW I was wrong, my dirty hack with add_with_viewport does not really solve the problem.

[jaap-karssenberg]

Running Ubuntu gnome and windows 10. Both with up to date gtk (need to check the version). Maybe KDE is involved. Do you have an easy option to test a different window manager on the same system?

…

On Fri, Feb 1, 2019, 09:22 Pierre Rust ***@***.*** wrote: I'm using gtk 3.22.30-1ubuntu1, but it's on a kde desktop (in case that could explain anything). What do you have on your system ? I've tested on another box (with an mate desktop) and I don't have the bug. BTW I was wrong, my dirty hack with add_with_viewport does not really solve the problem. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#642 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMMHgxjdjyeJicdCnIi1oYW-g-XAYKaks5vI_ktgaJpZM4aZzpn> .

[Roboron3042]

I can confirm this is happening in mi Arch Linux KDE Plasma installation. Not only code blocks are affected, but tables too.
I've tried running Zim in LXQt and openbox standalone - the behavior is the same.

On the bright side, pages aren't freezing anymore.

[jaap-karssenberg]

Would really want this resolved before releasing 0.70 - but cant reproduce and debug myself as my systems do not show this problem.

[Roboron3042]

I kept investigating: installing GNOME, uninstalling KDE, LXQt, running some GNOME based live distributions inside a VM (Ubuntu and Manjaro GNOME so far). Everything suffers from the same bug. Definitely not KDE/Qt related and widely reproducible.

Edit: Also tried Manjaro MATE with no luck (actually, it worked fine the first or second time i tried to replicate the bug. When it worked fine, reloading the page (CTRL+R) caused the bug to appear, and then it didn't work as expected anymore).

[PierreRust]

I've also tried it with:

• xubuntu 18.04 (i.e. GTK based) : no issue)
• kubuntu 18.10 (my initial report was for 18.04) : same problem

18.10 also upgrades gtk, but that does not solve the issue:

pierre:~$ pkg-config --modversion gtk+-3.0
3.24.1

I've tried to look at the code but I don't understand what happens, it seems that the code widget uses more place, when drawing, that what was assigned to it, which causes it to overlap the text (which has be placed according to expected size).

[PierreRust]

@Roboron3042 strange, you can reproduce the issue with ubuntu ? Which version ? and which gtk version ?

[Roboron3042]

@PierreRust I've tried both Ubuntu 18.04 and Ubuntu 18.10 (gtk+ 3.24.1).

[jhakonen]

Happens to me as well with 0.70. Didn't have this issue with 0.69.
Using Ubuntu 18.10.

EDIT: I can workaround the problem by switching from Zim to another application (e.g. using alt+tab) and then switching back to Zim. The page content updates, moving code blocks to their proper places (easier to see with Zim's window maximized, and the other app's window smaller). May need to switch apps couple of times for the page to fully update.

[alk0]

Hm, alt-tabbing does nothing for me, while resizing the window does (any resize at all — maximizing or just shrinking/enlarging one pixel). But just for the currently open page, so it's very far from being a workaround. Linux Mint 19.1/Cinnamon (Ubuntu 18.04), GTK 3.22.30-1ubuntu2

[jaap-karssenberg]

If resizing the window fixes the issue temporarily, this suggest it could be fixed by forcing the window manager to redraw the zim window after a page is loaded.

The right moment to do this is probably after the page is loaded at the end of PageView.set_page().

I can't say what would be the exact way to do it, but I would try things like queue_draw() and queue_resize() (see https://developer.gnome.org/gtk3/stable/GtkWidget.html).

Unfortunately I can't experiment myself, as the issue doesn't occur on my system; so hope someone with the issue can experiment and guide towards a patch.

Regards,

Jaap

[jaap-karssenberg]

P.S. looks like it is not related to the specific Gtk version. I suspect the window manager backend has some interaction with how the drawing is done but can't pinpoint exact trigger.

[alk0]

Found another "workaround" - Ctrl +, Ctrl - (zoom in/out; but not Ctrl 0) forces the page to reflow, sometimes fixing the current view (of the current portion of the page), but it does it differently from resizing a window, it is visibly slow, it still misplaces the codeblocks, and it can cause nasty drawing artifacts. And maybe it's a new different problem at all. Screenshot below >>

[jhakonen]

I can't actually reproduce this issue with OP's example. In fact, the page needs to be fairly large for the issue come up. Just some paragraphs of text and few code views don't seem to cut it for me.

Here's a page from my notebook which always seems to have this issue:
MsiLinux.txt

E.g.:

Also, when scrolling the page I see a constant spam of gtk warnings in stdout (after removing lines 873-878 in zim/main/init.py):
(zim.py:11789): Gtk-WARNING **: 20:31:30.873: Negative content height -1 (allocation 1, extents 1x1) while allocating gadget (node box, owner GtkVBox)
(zim.py:11789): Gtk-WARNING **: 20:31:30.873: gtk_widget_size_allocate(): attempt to allocate widget with width 972 and height -5

Relevant lines in GTK sources:

• https://github.com/GNOME/gtk/blob/3.24.4/gtk/gtkwidget.c#L6106
• https://github.com/GNOME/gtk/blob/3.24.4/gtk/gtkcssgadget.c#L781

Additional weirdness comes when your scroll the page so that one or more of the "floating" code views is over the top edge of the page view, partially clipped. Once there, scroll the page few lines up and then few lines down, rinse and repeat. As a result the code view's width starts to reduce, and can become quite narrow, e.g.:

The second warning's width value seems correlate with the reducing width. The width value in the warning reduces at same time as the code view becomes smaller.

I tried applying those queue_draw() and queue_resize() calls in the set_page()'s end, but they didn't seem to do anything visible.

[jaap-karssenberg]

@jhakonen thanks a lot ! With that test case now I can reproduce - my test pages were too simple ...

[jaap-karssenberg]

Observations so far:

• Not zim specific, I can reproduce the issue with a very basic script
• Seems to depend on embedding textviews - e.g. embedded image objects do not reproduce
• Only reproduces when there are more than 10 to 15 embedded objects
• As soon as the window is resized, all snaps back into place

Real fix needs to be in Gtk up stream, but can't say how and where.

Still hoping a workaround is possible forcing the same refresh as the window resize after loading each page.

[alk0]

My guess is that it might be some kind of sync/timing issue (in GTK?) (timeouts, race condition, whatever), because:

1. I have a rather weak PC, and I can surely observe this behavior with less than 10-15 blocks (just tested with 8)
2. When maximized, I can observe it with less blocks, compared to a small zim window
3. When I tried to record a video, background encoding (→high CPU load) seemingly increased the percentage of "faulty renders" in that border case scenario (with a minimal amount of blocks where sometimes it manages to reflow, and sometimes not).

Attached is a screen recording (.mkv, zipped, 27 seconds, <300 kb) — a few "bad" renders followed by a "good" reflow (happens at random, seems to depend on factors mentioned above).

Video — screen_recording-2019-04-08_17.18.03-recode.zip
Page source — test.txt

[jaap-karssenberg]

This is the hack I came up with last night. My limited testing shows it works although you take a small time penalty on rendering the page. Please help testing this. Regards, Jaap

…

On Mon, Apr 8, 2019 at 2:47 PM alk0 ***@***.***> wrote: My guess is that it might be some kind of sync/timing issue (in GTK?) (timeouts, race condition, whatever), because: 1. I have a rather weak PC, and I can surely observe this behavior with less than 10-15 blocks (just tested with 8) 2. When maximized, I can observe it with less blocks, compared to a small zim window 3. When I tried to record a video, background encoding (→high CPU load) seemingly increased the percentage of "faulty renders" in that border case scenario (with a minimal amount of blocks where sometimes it manages to reflow, and sometimes not). Attached is a screen recording (.mkv, zipped, 27 seconds, <300 kb) — a few "bad" renders followed by a "good" reflow (happens at random, seems to depend on factors mentioned above). Video — screen_recording-2019-04-08_17.18.03-recode.zip <https://github.com/zim-desktop-wiki/zim-desktop-wiki/files/3054269/screen_recording-2019-04-08_17.18.03-recode.zip> Page source — test.txt <https://github.com/zim-desktop-wiki/zim-desktop-wiki/files/3054296/test.txt> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#642 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMMHtbelynEm0XekI9SXvWTtb01vL5rks5vezpGgaJpZM4aZzpn> .

[alk0]

Uhm, can't see any relevant commits or attached patches yet. Later?

[jaap-karssenberg]

Oops, didn't realize github does not show attachments. Patch attached - please test it - thanks !

Patch here: https://gist.github.com/jaap-karssenberg/b40ef92149b86f3e0bc273369f4caa90

[alk0]

Seems to be working, I couldn't find any breaking example. The delay is negligible. I'd say, it's usable now, so, until we have a better solution, this is much better than nothing!

But: the overall page rendering speed seems to be, like, 100? 1000? times slower in 0.70 compared to 0.69, anyway, with or without the hack (only when code blocks are present). It is very much noticeable when trying to scroll a big page up and down (~200 Kb, 4000 lines, 200 code blocks) — as if it tries to re-render and reposition all code blocks on the page on each viewport change.

[jaap-karssenberg]

Noticed the hack also needs to be activated after pasting content - else pasting content with many code blocks also leads to rendering issues. Probably for good measure it should be activated after each object or parse tree insert. Speed wise it seems to scale with the amount of blocks you have in a page. This may be due to the underlying implementation in Gtk, not entirely sure. From our own code there is nothing that is triggered while scrolling.

…

On Tue, Apr 9, 2019 at 11:35 PM alk0 ***@***.***> wrote: Seems to be working, I couldn't find any breaking example. The delay is negligible. I'd say, it's usable now, so, until we have a better solution, this is much better than nothing! *But: the overall page rendering speed seems to be, like, 100? 1000? times slower in 0.70 compared to 0.69, anyway, with or without the hack (only when code blocks are present). It is very much noticeable when trying to scroll a big page up and down (~200 Kb, 4000 lines, 200 code blocks) — as if it tries to re-render and reposition all code blocks on the page on each viewport change.* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#642 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMMHp-xjfDA-mDRGZfNaB5Z3O0cgmIrks5vfQeegaJpZM4aZzpn> .

[PierreRust]

Ive just tested the patch as well, works fine for me.
I still get some gitch : a quick badly formated view of the page is displayed before the reflow happens, but after that everything is fine!

Many thanks for this, I was constantly switching between between zim's versions because of that issue 👍

[alk0]

Confirmed, after pasting the page is not recalculated.

Well, quick googling reveals that the Internet is full of complaints about speed in GTK3 compared to GTK2, particularly TextView; there were numerous complaints about scrolling as well, so — maybe you can do little about it until they fix it (if ever) :(

By the way, there's a small glitch in a codeblock itself — when pressing Enter on the last line, the line is added, but the height of the block is changed incorrectly. It is changed properly after adding another line, though. Should I register another bug? (it's low priority for me)

[alk0]

OK, posting it here:

• before
  
• after first Enter
  
• after second Enter
  

[AnonLibre]

Patch here: https://gist.github.com/jaap-karssenberg/b40ef92149b86f3e0bc273369f4caa90

ZIM / GTK rendered code blocks at wrong places in my text as well. With your patch code blocks are inserted correctly into the text flow again.

Thank you!

Distro: Manjaro Linux 18.0.4
Desktop: Xfce 4.12
Window Manager: xfwm4
GTK: gtk3 1:3.24.7+25+g17665f06e3-1

sudo patch \
  --directory=/usr/lib/python3.7/site-packages \
  --input=/home/anon/patches/zim/textview_allocation_hack.patch \
  --strip=1 \
  --backup

[jaap-karssenberg]

See #1693 for more recent version of this issue