Xpra: Ticket #760: debug option for subregion color coding according to encodings, quality, speed, etc?

Debugging issues, especially on annoyingly complicated applications like web browsers, is often complicated by the effort to try to discern what the problematic pieces are doing, before a narrowing of debug options is possible.

Would it be possible to add flags to color code the pieces in some way? Maybe something like --png=yellow, --h264=blue, or --quality-output=yes to have some sort of color boxing of subregions and maybe a rolling output of the numerical quality setting... or something like that?



Wed, 10 Dec 2014 00:07:14 GMT - Antoine Martin: status changed; milestone set

We do have the ability to paint boxes around the regions which get updated using the env var:

XPRA_OPENGL_PAINT_BOX=1 xpra attach ..

Limitations / blockers:


Fri, 26 Dec 2014 07:41:03 GMT - Antoine Martin: owner, status changed

Note "expose" is for paint events we do not trigger ourselves (OS repaints, usually due to windows being obscured/shown again). If the colors aren't practical for a specific debugging scenario, you can override them using the syntax XPRA_BOX_COLOR_{encoding}="{colorname}", ie:

XPRA_BOX_COLOR_H264="green"

It would be nice to be able to also overlay the quality / speed settings on regions that make use of it (video mostly, but also webp and jpeg) - but this would be far too much work, maybe later.

Ready for testing.

Here is a screenshot, where we can see h264 video (blue), and other areas in webp (pink) or png (yellow): shows the box paint in use with youtube


Fri, 26 Dec 2014 07:41:27 GMT - Antoine Martin: attachment set

shows the box paint in use with youtube


Sun, 28 Dec 2014 09:36:36 GMT - Antoine Martin:

To help with #756 and debugging delta in general, r8312 paints regions that were sent as delta using dotted lines.

Also note that r8302 paints the spinners using opengl now, see #353 for details.


Sun, 28 Dec 2014 10:16:51 GMT - Antoine Martin: summary changed

Also worth mentioning that r8316 allows us to disable region merging on the server:

XPRA_MERGE_REGIONS=0 xpra start ...

Which can be useful to visualize the regions that get updated, as we get them from the application (bar video regions - which can be disabled by not using a video encoding), disabling the heuristics that sometime merge them into bigger screen updates.


Sat, 17 Jan 2015 02:47:19 GMT - alas:

I tried: XPRA_BOX_COLOR=1, XPRA_OPENGL_PAINT_BOX=1, and XPRA_PAINT_BOX=1 ... on the client side - and I also tried XPRA_PAINT_BOX=1 server-side, all to no avail.

I assume you have a hint for a different one to try?


Sat, 17 Jan 2015 02:53:51 GMT - Antoine Martin:

I do not have an XP VM with opengl enabled to test on. Is opengl enabled on your windows test box?

But this definitely works with fedora clients for example. And the env var is named correctly in comment:1

export XPRA_OPENGL_PAINT_BOX=1
xpra attach --no-mmap tcp:192.168.1.100:10000

Fri, 23 Jan 2015 02:17:24 GMT - alas: status changed

Testing with your OSX beta build r8526 does work as expected (though, the framing lines aren't as bold as the screenshot included here in the ticket).

Could the "pango-querymodules" issues listed in #788 be the problem with my osx build?

Meanwhile, testing with a windows 0.15.0 r8522 client (against same fedora 20 0.15.0 r8527 server) still isn't working. The windows client has XPRA_OPENGL_PAINT_BOX=1 displaying from cmd window when I check with a set command, and the Session Info confirms that the opengl is enabled... but it is a mac-mini running with windows 8.1 bootcamped, and it has an Intel 4000 graphics card. Not sure if that could be the culprit, or if it might be something else in my/smo's build...


Fri, 23 Jan 2015 03:14:34 GMT - Antoine Martin:

though, the framing lines aren't as bold as the screenshot included here in the ticket


Are seeing what I described in comment:3 ? : To help with #756 and debugging delta in general, r8312 paints regions that were sent as delta using dotted lines.


mac-mini running with windows 8.1 bootcamped, and it has an Intel 4000 graphics card


Could well be part of the problem. That thing should have been blacklisted I think. You can confirm by trying with a win32 box with a proper graphics card.


Fri, 23 Jan 2015 19:58:56 GMT - alas:

Ok, testing with a windows 7 machine with an AMD video card and 0.15.0 r8534 client against a fedora 20 server 0.15.0 r8527 ... I do see the opengl paint boxes - mostly. It looks like the boxes aren't picking up by region with the windows client, but rather just indicating that the entire window is all one uniform encoding (whether h264 or delta or what have you).

Testing with a 0.15.0 r8534 osx client (with an Intel Iris graphics card, but with --opengl=on to force the opengl), on the other hand, the boxes appear as one would expect (illuminatingly so).

I'll attach a couple of screen shots to help that make sense.


Fri, 23 Jan 2015 20:00:32 GMT - alas: attachment set

osx client paint boxes - look like on fedora


Fri, 23 Jan 2015 20:01:36 GMT - alas: attachment set

opengl paint boxes on windows client shows only one encoding - h264 here


Fri, 23 Jan 2015 20:02:38 GMT - alas: attachment set

opengl paint boxes on windows client shows only one encoding - delta here


Fri, 23 Jan 2015 20:14:45 GMT - alas:

OSX client seems to behave as expected:


osx client paint boxes - look like on fedora


While windows clients seem to be encoding the entire screen uniformly (perhaps they are?) h264:


opengl paint boxes on windows client shows only one encoding - h264 here

delta (delta always seems to be png):


opengl paint boxes on windows client shows only one encoding - delta here


One interesting note - the windows paint boxes only seem to have frames on the left and lower edges of the application window (tested and behaves likewise with gedit and xterm both) - probably want to work on the boxes being attached to the encoding regions, but it occurs to me that the "whole window" box issue might be similar to the one of the min/max sizing where the window manager was using portions of the designated sizes for the frames and so on (IIRC). I'll also attach a full-size windows screen shot which should, hopefully, make that more apparent.


Fri, 23 Jan 2015 20:23:38 GMT - alas: attachment set

windows client with apparently all delta - full size


Sat, 24 Jan 2015 07:21:59 GMT - Antoine Martin:

While windows clients seem to be encoding the entire screen uniformly (perhaps they are?)


That window looks quite small and the video occupies 90% of it, so it is quite possible that we end up not detecting the video region.


delta (delta always seems to be png):


delta can be used by all rgb24, rgb32 and png. With a terminal it's quite easy to trigger rgb24+delta paints.


One interesting note - the windows paint boxes only seem to have frames on the left and lower edges of the application window


One way to confirm that would be to use -d paint and then visually reconcile the output with the rectangles painted on screen...


Wed, 11 Feb 2015 01:33:31 GMT - alas:

Testing with windows 8.1 client 0.15.0 r8647 against fedora 20 server 0.15.0 r8601...

I'm still not seeing the subsections boxed by encoding, even when I splay a window across a 4K monitor so that large portions are not video (attaching a mother-huge screen shot).

I'm able to see delta and not delta encodings at the same time, but since the boxes only appear on the edges of the windows (tested on firefox, chrome, and xterms), I can't tell which regions are being picked up with the delta encoding and which are being video encoded, and so on. (The delta dashes appear in tandem with the other encoding colorations.)

I grabbed a smaller screen shot with more detail to show the paint boxes on only the ... actually, the right and lower edge of the application window, and I'll attach a -d paint log bit, as well as a clip here (maybe it will be illustrative, I'm not sure quite what to make of it). Window screen shot'd is wid 3.

2015-02-10 17:08:36,309 Switching to RGB paint state
2015-02-10 17:08:36,309 BGRX 24bpp update at (11,549) size 895x21 (78120 bytes), stride=3720, row length 930, alignment 8, using GL ('zerocopy:memoryview', <type 'str'>) format=BGRA
2015-02-10 17:08:36,309 Presenting FBO on screen
2015-02-10 17:08:36,309 Switching to RGB paint state
2015-02-10 17:08:36,309 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_show() swapping buffers now
2015-02-10 17:08:36,309 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_frame_terminator()
2015-02-10 17:08:36,309 Switching back to YUV paint state
2015-02-10 17:08:36,309 <OpenGL.platform.baseplatform.glBindFramebuffer object at 0x06DAE7D0>(GL_FRAMEBUFFER (36160), c_ulong(1L))
2015-02-10 17:08:36,309 gtk2.GLWindowBacking(3, (930, 570), YUV444P).present_fbo() done
2015-02-10 17:08:36,309 record_decode_time(True) wid=3, rgb24: 895x21, 15.0ms
2015-02-10 17:08:36,309 after_draw_refresh(True) 895x21 at 11x549 encoding=rgb24, options={'encoding': 'rgb24', 'rgb_format': 'BGRX', 'bucket': 1, 'lz4': 1, 'delta': 1596, 'store': 1600}
2015-02-10 17:08:36,559 process_draw 52243 bytes for window 3 using h264 encoding with options={'pts': 113124, 'frame': 383, 'speed': 63, 'csc': 'YUV444P', 'quality': 99}
2015-02-10 17:08:36,559 draw_region(11, 34, 894, 514, h264, 52243 bytes, 0, {'pts': 113124, 'frame': 383, 'speed': 63, 'csc': 'YUV444P', 'quality': 99}, [<function record_decode_time at 0x0723A7B0>, <function after_draw_refresh at 0x0723A3B0>])
2015-02-10 17:08:36,559 process_draw 977 bytes for window 3 using rgb24 encoding with options={'lz4': 1, 'rgb_format': 'BGRX'}
2015-02-10 17:08:36,559 gl_paint_planar(<class 'xpra.codecs.dec_avcodec2.decoder.AVImageWrapper'>(YUV444P:(0, 0, 894, 514, 24):3_PLANES)-(None), 11, 34, 894, 514, 894, 514, [<function record_decode_time at 0x0723A7B0>, <function after_draw_refresh at 0x0723A3B0>])
2015-02-10 17:08:36,559 draw_region(905, 34, 1, 515, rgb24, 977 bytes, 4, {'lz4': 1, 'rgb_format': 'BGRX'}, [<function record_decode_time at 0x0723A730>, <function after_draw_refresh at 0x0723A430>])
2015-02-10 17:08:36,559 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_context() GL Pixmap backing size: 930 x 570, context=gtk2.GLContextManager(<gtk.DrawingArea object at 0x71fba30 (GtkDrawingArea at 0x3bd3d48)>)
2015-02-10 17:08:36,559 gtk2.GLWindowBacking(3, (930, 570), YUV444P).update_planar_textures(11, 34, 894, 514, <class 'xpra.codecs.dec_avcodec2.decoder.AVImageWrapper'>(YUV444P:(0, 0, 894, 514, 24):3_PLANES)-(None), 'YUV444P')
2015-02-10 17:08:36,559 process_draw 1973 bytes for window 3 using rgb24 encoding with options={'lz4': 1, 'rgb_format': 'BGRX'}
2015-02-10 17:08:36,559 updating planar textures: 894x514 YUV444P
2015-02-10 17:08:36,559 draw_region(11, 548, 906, 1, rgb24, 1973 bytes, 3720, {'lz4': 1, 'rgb_format': 'BGRX'}, [<function record_decode_time at 0x0723A830>, <function after_draw_refresh at 0x0723A8F0>])
2015-02-10 17:08:36,559 texture 0: div=(1, 1), rowstride=896, 894x514, data=460544 bytes
2015-02-10 17:08:36,559 process_draw 20183 bytes for window 3 using rgb24 encoding with options={'delta': 1600, 'bucket': 1, 'lz4': 1, 'store': 1604, 'rgb_format': 'BGRX'}
2015-02-10 17:08:36,559 draw_region(11, 549, 895, 21, rgb24, 20183 bytes, 3720, {'delta': 1600, 'bucket': 1, 'lz4': 1, 'store': 1604, 'rgb_format': 'BGRX'}, [<function record_decode_time at 0x0723A770>, <function after_draw_refresh at 0x0723A630>])
2015-02-10 17:08:36,559 texture 1: div=(1, 1), rowstride=896, 894x514, data=460544 bytes
2015-02-10 17:08:36,575 texture 2: div=(1, 1), rowstride=896, 894x514, data=460544 bytes
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).render_planar_update(11, 34, 894, 514, 1, 1) pixel_format=YUV444P
2015-02-10 17:08:36,575 painting planar update, format YUV444P
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).render_planar_update(..) texture_size=(894, 514), size=(930, 570)
2015-02-10 17:08:36,575 Presenting FBO on screen
2015-02-10 17:08:36,575 Switching to RGB paint state
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_show() swapping buffers now
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_frame_terminator()
2015-02-10 17:08:36,575 Switching back to YUV paint state
2015-02-10 17:08:36,575 <OpenGL.platform.baseplatform.glBindFramebuffer object at 0x06DAE7D0>(GL_FRAMEBUFFER (36160), c_ulong(1L))
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).present_fbo() done
2015-02-10 17:08:36,575 record_decode_time(True) wid=3, h264: 894x514, 16.0ms
2015-02-10 17:08:36,575 after_draw_refresh(True) 894x514 at 11x34 encoding=h264, options={'quality': 99, 'encoding': 'h264', 'speed': 63, 'frame': 383, 'csc': 'YUV444P', 'pts': 113124}
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P)._do_paint_rgb(24, 2060 bytes, x=905, y=34, width=1, height=515, rowstride=4, options={'encoding': 'rgb24', 'lz4': 1, 'rgb_format': 'BGRX'})
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_context() GL Pixmap backing size: 930 x 570, context=gtk2.GLContextManager(<gtk.DrawingArea object at 0x71fba30 (GtkDrawingArea at 0x3bd3d48)>)
2015-02-10 17:08:36,575 Switching to RGB paint state
2015-02-10 17:08:36,575 BGRX 24bpp update at (905,34) size 1x515 (2060 bytes), stride=4, row length 0, alignment 4, using GL ('zerocopy:memoryview', <type 'str'>) format=BGRA
2015-02-10 17:08:36,575 Presenting FBO on screen
2015-02-10 17:08:36,575 Switching to RGB paint state
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_show() swapping buffers now
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_frame_terminator()
2015-02-10 17:08:36,575 Switching back to YUV paint state
2015-02-10 17:08:36,575 <OpenGL.platform.baseplatform.glBindFramebuffer object at 0x06DAE7D0>(GL_FRAMEBUFFER (36160), c_ulong(1L))
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).present_fbo() done
2015-02-10 17:08:36,575 record_decode_time(True) wid=3, rgb24: 1x515, 16.0ms
2015-02-10 17:08:36,575 after_draw_refresh(True) 1x515 at 905x34 encoding=rgb24, options={'encoding': 'rgb24', 'lz4': 1, 'rgb_format': 'BGRX'}
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P)._do_paint_rgb(24, 3720 bytes, x=11, y=548, width=906, height=1, rowstride=3720, options={'encoding': 'rgb24', 'lz4': 1, 'rgb_format': 'BGRX'})
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_context() GL Pixmap backing size: 930 x 570, context=gtk2.GLContextManager(<gtk.DrawingArea object at 0x71fba30 (GtkDrawingArea at 0x3bd3d48)>)
2015-02-10 17:08:36,575 Switching to RGB paint state
2015-02-10 17:08:36,575 BGRX 24bpp update at (11,548) size 906x1 (3720 bytes), stride=3720, row length 930, alignment 8, using GL ('zerocopy:memoryview', <type 'str'>) format=BGRA
2015-02-10 17:08:36,575 Presenting FBO on screen
2015-02-10 17:08:36,575 Switching to RGB paint state
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_show() swapping buffers now
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).gl_frame_terminator()
2015-02-10 17:08:36,575 Switching back to YUV paint state
2015-02-10 17:08:36,575 <OpenGL.platform.baseplatform.glBindFramebuffer object at 0x06DAE7D0>(GL_FRAMEBUFFER (36160), c_ulong(1L))
2015-02-10 17:08:36,575 gtk2.GLWindowBacking(3, (930, 570), YUV444P).present_fbo() done

Wed, 11 Feb 2015 01:34:28 GMT - alas: attachment set

window on 4K monitor, opengl paint box markers only on edges of window


Wed, 11 Feb 2015 01:35:15 GMT - alas: attachment set

small window, with delta and general encoding in tandem - only showing on edges


Wed, 11 Feb 2015 01:36:01 GMT - alas: attachment set

Overly verbose windows client logs with -d paint


Wed, 11 Feb 2015 03:51:17 GMT - Antoine Martin: owner, status changed

OK, taking the ticket back.

I'll test it on real win32 system with a real graphics card. (win32 uses double buffering, Linux does not..)


Fri, 01 May 2015 03:09:57 GMT - Antoine Martin: owner, milestone changed

Is this still an issue? I don't have a real win32 system to test on with me right now.


Thu, 07 May 2015 22:24:44 GMT - alas:

Yes... testing with 0.15.0 r9202 on windows against a 0.15.0 r9137 fedora 20 server... windows behaves exactly the same as above.

Unfortunately, with an OSX 0.15.0 r9202 client I am not seeing any paintbox display at all now. (Yes, running with an intel graphics card, but overriding with --opengl=on.)

Are there any particular logs that would help?


Mon, 11 May 2015 16:31:47 GMT - Antoine Martin:

Yes, running with an intel graphics card, but overriding with --opengl=on.


There was a bug which prevented the command line option from overriding the platform safety checks. This is fixed in r9302 (backport to v0.15.x in r9303)

You should have been able to see that the opengl option was not enabled in your tray menu. Toggling it would have enabled opengl.

Once opengl is enabled, the box feature works fine here on my mac-mini. @afarr: I don't have a win32 system to test on yet (bootcamp and/or win7+4k monitor giving me grief), can you confirm that win32 is also fixed? (I hope it was another case of greylisted intel card causing opengl to be turned off)


Tue, 12 May 2015 05:46:24 GMT - Antoine Martin:

As of r9305 (r9306 for v0.15.x) we show "disabled" in session info if the card is greylisted.


Tue, 12 May 2015 05:58:05 GMT - Antoine Martin:

As of r9307 (trunk only), changes to the opengl state done via the systray will be reflected in session-info. (could backport - low priority)


Fri, 15 May 2015 00:41:03 GMT - alas:

Testing with OSX 0.15.0 r 9365 client against fedora 20 0.15.0 r9365 server - paintboxes are again displaying as expected. The Features menu also gives the option to turn opengl on/off, which works and turns the paintboxes off again as expected. Session Info correctly lists whether opengl is enabled or disabled (not sure if Intel is currently greylisted or blacklisted ... but the osx client-side output indicates OpenGL_accelerate module loaded, despite the default being disabled, without also indicating either greylist or blacklist.

Testing against the same server session with a 0.15.0 r9365 win32 client - I still don't see any regions paintboxed, except the outermost edges of a window (as if the entire browser window were being encoded alternately in webp or h264, rather than sections being variously encoded). Same as the images already posted.

This is, again, a mac-mini with intel card bootcamping windows 8.1. With no flags used one way or the other, the opengl is indicated to be on, and the window edges are at least paintboxed. Using the tray I can turn opengl off, which is reflected in session info, and which eliminates all trace of paintboxes.

I'll attach a client-side log of a long 2 seconds with -d paint, with an inactive xterm and a firefox window with video playing in frame, and a little scrolling of that window.


Fri, 15 May 2015 00:42:21 GMT - alas: attachment set

quick snippet of logs attaching to an active session with a firefox window with a video region playing, and a tiny bit of scrolling


Fri, 15 May 2015 02:51:28 GMT - Antoine Martin: owner, status changed

I'll test some more once I manage to bootcamp something with my 4k screen.

Until then, I think this is because win32 uses double-buffering, so we always repaint the whole window and the box overlay gets lost.


Tue, 19 May 2015 12:59:09 GMT - Antoine Martin:

Confirmed as a double-buffering issue by running the linux client with:

XPRA_OPENGL_DOUBLE_BUFFERED=1 XPRA_OPENGL_PAINT_BOX=1 xpra attach ..

The boxes are no longer painted on screen. (just the edge)

Not sure what to do about this one.


Sat, 23 May 2015 10:26:50 GMT - Antoine Martin: owner, status changed

This should be fixed in trunk r9504, it now works on Linux with double buffering enabled using:

XPRA_OPENGL_DOUBLE_BUFFERED=1 XPRA_OPENGL_PAINT_BOX=1 xpra attach ..

BTW, double buffering works OK on Linux, maybe we ought to switch to that?

It works on OSX too (tested on 10.10), but not with double buffering enabled!?

Please verify on win32, and maybe try to make it crash, somehow. Please also check that the border command line option also works there. (this one works on OSX with and without double buffering, but it still uses paint from the present stage - so it might not work on win32?) To use it:

xpra attach --border=auto,10

Thu, 28 May 2015 01:10:43 GMT - alas:

Accidentally tested on osx with 0.15.0 r9533 client.

The opengl paint boxes displayed not only without any double buffering enabled, but without the use of any flags.

Turning on the subregion debugging server side didn't elucidate what might be going on any - for me at least. All the server was outputting was:

2015-05-27 17:57:31,789 send_delayed_regions: substracted rectangle[41, 106, 676, 425] from [R(38, 151, 679, 380),R(38, 531, 287, 3), R(155, 534, 67, 22)] gives us [R(38, 151, 3, 380), R(38, 531, 287, 3), R(155, 534, 67, 22)]
2015-05-27 17:57:31,789 send_delayed_regions: delaying non video regions some more
2015-05-27 17:57:31,790 send_delayed_regions: video region rectangle[41, 106, 676, 425] not found in: [R(38, 151,  3, 380), R(38, 531, 287, 3), R(155, 534, 67, 22)] (using non video encoding)
2015-05-27 17:57:31,817 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:31,849 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:31,880 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:31,920 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:31,955 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:31,986 send_delayed_regions: substracted rectangle[41, 106, 676, 425] from [R(38, 151, 679, 380), R(38, 531, 287, 3), R(155, 534, 67, 22)] gives us [R(38, 151, 3, 380), R(38, 531, 287, 3), R(155, 534, 67, 22)]
2015-05-27 17:57:31,986 send_delayed_regions: delaying non video regions some more
2015-05-27 17:57:31,987 send_delayed_regions: video region rectangle[41, 106, 676, 425] not found in: [R(38, 151, 3, 380), R(38, 531, 287, 3), R(155, 534, 67, 22)] (using non video encoding)
2015-05-27 17:57:32,015 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:32,044 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:32,087 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:32,118 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]
2015-05-27 17:57:32,148 send_delayed_regions: nothing left after removing video region rectangle[41, 106, 676, 425]

Is there a better debug flag to try?


Thu, 28 May 2015 04:06:17 GMT - Antoine Martin:

First, as per comment:22, the fix is in trunk, not in 0.15 or older. I'm not taking any chances of breaking the stable branches with a debugging feature.

But even then, the code is very similar and I don't see how it is possible to trigger without setting the environment variable, here's how we paint the boxes:

    def paint_box(self, encoding, is_delta, x, y, w, h):
        #show region being painted if debug paint box is enabled only:
        if not OPENGL_PAINT_BOX:
            return
        ...

And the value is obtained from (same for all branches):

OPENGL_PAINT_BOX = os.environ.get("XPRA_OPENGL_PAINT_BOX", "0")=="1"

So, unless XPRA_OPENGL_PAINT_BOX is set to "1" explicitly, it defaults to "0", OPENGL_PAINT_BOX will evaluate to False and we shortcut out of paint_box immediately.

Having a screenshot wouldn't hurt. Maybe you're talking about the window border switch and not the boxes? I have uploaded 0.15 and 0.16 osx beta builds so that you can verify that this is not an issue with your build environment.

The subregion code has very little to do with paint boxes.


Fri, 29 May 2015 01:50:53 GMT - alas:

Testing again, I'm not seeing the paintboxes now. Apparently I managed to set the osx environment variable independent of the flags, so ignore comment:23.

I'll put the win32 client through its paces very soon, and do further osx testing very soon.


Mon, 01 Jun 2015 23:04:04 GMT - alas:

Testing with osx & win32 0.15.0 r9533 clients against a fedora 20 0.15.0 r9533 server... I'm still not seeing opengl paintboxes displaying correctly on windows (still displays around the exterior frame of the windows). Just out of curiosity, I also tried the windows client with XPRA_OPENGL_DOUBLE_BUFFERED=1 ... which, not surprisingly, resulted in the same paint box display on exterior of window frame.

With the osx client, without using the XPRA_OPENGL_DOUBLE_BUFFERED=1 environment variable, the paintboxes display as expected... but once setting the double buffering to on the osx client displays like the win32, with the color displays showing only at the exterior of the frame.


Mon, 01 Jun 2015 23:14:54 GMT - alas:

One last note... testing the border setting with the win32 client, I notice that an increase in the border size (with xpra_cmd.exe attach --border=auto,47) results in the border "covering up" the OPENGL_PAINT_BOXes.

I also notice that there seems to be an upper limit to what I can do going crazy with the border settings - I see no difference between border=47 and border=470000.


Tue, 02 Jun 2015 04:43:42 GMT - Antoine Martin:

Testing with osx & win32 0.15.0 ..


As per comment:22 and again in comment:24: the fix is in trunk, not in 0.15 or older.


I also notice that there seems to be an upper limit to what I can do going crazy with the border settings


Each OpenGL driver has a limit on the width of the lines it can paint (which we use for painting the border), which is fine - having a border that wide is not very useful - we now clip it ourselves at 45 pixels in r9563 to prevent opengl driver issues with crazy large values (seems reasonable I think).

See glLineWidth. It would be better to query what the limit is rather than clipping to an arbitrary value, but this will do for now. I guess we could also switch to polygons to workaround this limitation.


Thu, 27 Aug 2015 01:54:55 GMT - alas:

So I finally got the hint (took enough time to actually RTF-ticket)... and tested with trunk (0.16 r10442 win client, r10306 fedora21 server).

Paintboxes are working brilliantly just by using environment variable XPRA_OPENGL_PAINT_BOX=1.

I can't seem to change the border size with border=4 v. border=43 either server or client side (or both).


Thu, 27 Aug 2015 04:36:58 GMT - Antoine Martin:

Did you test all platforms? (win32, osx and Linux)

Can I close this ticket?


I can't seem to change the border size with border=4 v. border=43 either server or client side (or both).


The border command line switch only affects window borders, which is not a debugging feature. If this doesn't work, please file a new ticket for that (works fine here on the platforms I tested - you just need to use the correct syntax).

r10450 changes the meaning of the XPRA_OPENGL_PAINT_BOX env switch, it now specifies the line width, so 0 keeps it disabled as before (and is the default). ie: XPRA_OPENGL_PAINT_BOX=10 xpra ...


Thu, 17 Sep 2015 23:54:23 GMT - alas: status changed; resolution set

Tested with OSX, windows (working in trunk) and fedora.

I'll close this myself.


Thu, 25 Feb 2016 08:32:43 GMT - Antoine Martin:

Note: as of r12054 you can toggle the paint box at runtime using Meta+Shift+F12.


Sat, 23 Jan 2021 05:05:09 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/760