incomplete redraw: black rectangle on right-hand side

[totaam]

Issue migrated from trac ticket # 252

component: core | priority: critical | resolution: fixed

2013-02-11 01:38:00: onlyjob created the issue

---

Some dialogs are rendered incomplete with black rectangle on right-hand side.

The attached screenshot demonstrate the problem on a dialog in gnucash application (enter payment for invoice): [[Image(/raw-attachment/ticket/252/xpra_gnucash-enter-payment.png)]]

I've also seen the described effect in ktorrent when it is just started before session is attached.

Here are the instructions how to reproduce in Iceweasel (aka Firefox): You need "tree style tab" extension activated. In its properties set "Auto hide" --> "For Normal Window Mode" to "Auto Shrink tab bar". Assuming that tab list on the left hand side, when you hover it, it should expand and become wider partially overlapping web page content with transparency effect. Now there is a weird part: if you open a particular web page:

    http://phoronix.com/forums/forum.php

and move mouse cursor over tree-tabs it will expand but the web page will be hidden under big black rectangle until tree tab shrinks itself (when you move the mouse cursor away). I can easily reproduce that in local session (i.e. the bug is manifesting with all encodings) on phoronix.com and few other web sites.

This is not a regression and was present in previous Xpra versions.

[totaam]

2013-04-24 11:20:08: onlyjob commented

---

Nope, this patch didn't help either. It looks like it has no effect.

Is there anything else that I could try? ;)

[totaam]

2013-04-24 11:49:10: totaam commented

---

Can you please run the client with this patch, encoding=rgb24, no opengl:

--- src/xpra/window_backing.py    (revision 3132)
+++ src/xpra/window_backing.py    (working copy)
@@ -378,6 +378,7 @@
             fire_paint_callbacks(callbacks, False)

     def _do_paint_rgb24(self, img_data, x, y, width, height, rowstride, options, callbacks):
+        log.info("_do_paint_rgb24: updating pixmap backing %s with rgb24 data %s at %s,%s", self._backing.get_size(), (width, height), x, y)
         gc = self._backing.new_gc()
         self._backing.draw_rgb_image(gc, x, y, width, height, gdk.RGB_DITHER_NONE, img_data, rowstride)
         return True

We should see something like this:

_do_paint_rgb24: updating pixmap backing (420, 220) with rgb24 data (420, 220) at 0,0

But when the window misbehaves, my guess is that the backing size will not match the rgb24 data size..

---

I've added what should be a better test case in r3138: running this test app tries to mimic what the gnucash window does: realize the window, resize it, show it then resize it again. (with some event logging) I believe I've already spotted problems:

• had a case where the client window stayed black (no idea why)
• the client window remains at 420x220 even after the application resizes itself to 440x240...

[totaam]

2013-04-24 12:07:30: onlyjob commented

---

I got flow of the following lines:

2013-04-24 21:02:56,474 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:56,477 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:56,857 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:56,997 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:02:57,359 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:02:57,365 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (482, 232) at 0,0
2013-04-24 21:02:57,410 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:57,438 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:57,488 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:57,493 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (287, 198) at 4,23
2013-04-24 21:02:57,500 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:57,789 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:57,848 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:02:58,114 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:02:58,201 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (482, 232) at 0,0
2013-04-24 21:02:58,215 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:58,259 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:58,307 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:58,319 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:58,323 _do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (287, 198) at 4,23
2013-04-24 21:02:58,597 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:58,620 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:02:58,864 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:02:58,952 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:58,976 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:59,042 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (552, 274) at 0,0
2013-04-24 21:02:59,079 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 70,24
2013-04-24 21:02:59,794 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (219, 20) at 72,130
2013-04-24 21:03:00,195 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (219, 20) at 72,130
2013-04-24 21:03:00,690 _do_paint_rgb24: updating pixmap backing (1374, 748) with rgb24 data (36, 36) at 682,24
2013-04-24 21:03:01,001 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (219, 20) at 72,130
2013-04-24 21:03:01,009 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (63, 27) at 228,19
2013-04-24 21:03:01,021 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (63, 54) at 228,19
2013-04-24 21:03:01,041 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (63, 27) at 228,46
2013-04-24 21:03:01,078 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (85, 27) at 369,240
2013-04-24 21:03:01,087 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (85, 27) at 369,240
2013-04-24 21:03:01,396 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (219, 20) at 72,130
2013-04-24 21:03:01,408 _do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (219, 20) at 72,130

Because it's a flow (even when there are no events or mouse movements) it is a bit difficult to isolate those that correspond to broken window...

[totaam]

2013-04-24 12:45:58: totaam commented

---

As I expected:

_do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (552, 274) at 0,0

Is what we should be seeing all along, but we also see afterwards:

_do_paint_rgb24: updating pixmap backing (482, 232) with rgb24 data (552, 274) at 0,0

Which means that the client window backing is too small at that point.

And then this really odd one:

_do_paint_rgb24: updating pixmap backing (552, 274) with rgb24 data (482, 232) at 0,0

Which means that at that point the client was correct, but the server was not!

It's a race... and we need the server to win it, sometimes. Arghh.

[totaam]

2013-10-22 16:31:09: antoine commented

---

FYI: comment:24 was wrong about the overlay layer being transparent (since we now do tranparency too - see #279), but probably not about the cause (there is some layer overlaid on top - as demonstrated by removing html sections)

[totaam]

2014-01-10 08:32:27: totaam changed status from assigned to new

[totaam]

2014-01-10 08:32:27: totaam changed owner from totaam to onlyjob

[totaam]

2014-01-10 08:32:27: totaam commented

---

Apparently this is fixed? If so please close Any idea when it was fixed?

[totaam]

2014-01-16 02:35:56: onlyjob changed status from new to closed

[totaam]

2014-01-16 02:35:56: onlyjob changed resolution from * to fixed*

[totaam]

2014-01-16 02:35:56: onlyjob commented

---

I did not see this problem since upgrade (from 0.10.9) to 0.10.10 so I believe exactly 0.10.10 fixed it. Apparently both symptoms are gone -- black box on tree-style-tab expansion in Firefox as well as incomplete dialog in Gnucash. (I'm not 100% sure about the latter since it was harder to reproduce and I use Gnucash far less often that Firefox. Yet it appears to be fixed as when dialog is shown the black area on its right-hand side is visible for a moment just before dialog renders completely). Closing.