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

totaam · 2014-12-09T23:38:47Z

Issue migrated from trac ticket # 760

component: client | priority: minor | resolution: fixed

2014-12-09 23:38:47: afarr created the issue

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?

The text was updated successfully, but these errors were encountered:

totaam · 2014-12-10T00:07:15Z

2014-12-10 00:07:15: antoine changed status from new to assigned

totaam · 2014-12-10T00:07:15Z

2014-12-10 00:07:15: antoine commented

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:

this is only implemented for opengl (not pixbuf or cairo / gtk3)

it was only working for single buffered backends (Linux but not win32)

the colour is hard-coded for now - I like the idea of giving each encoding its own colour

I think it broke in the last release(s)

I don't have time or skills to fix all the opengl issues: opengl backend should preserve fbo contents when resizing #478, opengl improvements: double buffering, limited repaints, paint state #679 (linking it back here)

totaam · 2014-12-26T07:41:03Z

2014-12-26 07:41:03: antoine changed status from assigned to new

totaam · 2014-12-26T07:41:03Z

2014-12-26 07:41:03: antoine changed owner from antoine to afarr

totaam · 2014-12-26T07:41:03Z

2014-12-26 07:41:03: antoine commented

r8288 fixes the "paint box" and "border" paint modes with opengl, found the solution here: How do you render a texture without being affected by glColor?, a good explanation can be found here: jogl: Textures and Blending

r8289 adds colors, here are the defaults used:
_DEFAULT_BOX_COLORS = {
              "png"     : "yellow",
              "h264"    : "blue",
              "vp8"     : "green",
              "rgb24"   : "orange",
              "rgb32"   : "red",
              "webp"    : "pink",
              "jpeg"    : "purple",
              "png/P"   : "indigo",
              "png/L"   : "teal",
              "h265"    : "khaki",
              "vp9"     : "lavender",
              "expose"  : "violet",
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):
[[Image(box-colors.png)]]

totaam · 2014-12-26T07:41:28Z

2014-12-26 07:41:28: antoine uploaded file `box-colors.png` (371.6 KiB)

shows the box paint in use with youtube

totaam · 2014-12-28T09:36:37Z

2014-12-28 09:36:37: totaam commented

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.

totaam · 2014-12-28T10:16:52Z

2014-12-28 10:16:52: totaam changed title from Would it be possible to have a debug flag added that would allow for subregion color coding according to encodings, quality, speed, etc? to debug option for subregion color coding according to encodings, quality, speed, etc?

totaam · 2014-12-28T10:16:52Z

2014-12-28 10:16:52: totaam commented

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.

totaam · 2015-01-17T02:47:19Z

2015-01-17 02:47:19: afarr commented

Testing with windows client 0.15.0 8423 against a fedora 20 0.15.0 r8413 I tried to use a variety of environment variables to engage the boxes, but don't seem to have found the right one.

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?

totaam · 2015-01-17T02:53:51Z

2015-01-17 02:53:51: totaam commented

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

totaam · 2015-01-23T02:17:25Z

2015-01-23 02:17:25: afarr changed status from new to assigned

totaam · 2015-01-23T02:17:25Z

2015-01-23 02:17:25: afarr commented

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 8522 client (against same fedora 20 0.15.0 8527 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...

totaam · 2015-01-23T03:14:35Z

2015-01-23 03:14:35: totaam commented

though, the framing lines aren't as bold as the screenshot included here in the ticket
[[BR]]
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.

[[BR]]

mac-mini running with windows 8.1 bootcamped, and it has an Intel 4000 graphics card
[[BR]]
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.

totaam · 2015-01-23T19:58:57Z

2015-01-23 19:58:57: afarr commented

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 8527 ... 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.

totaam · 2015-01-23T20:00:32Z

2015-01-23 20:00:32: afarr uploaded file `ticket760_opengl-paint-boxes_osx8534.png` (855.0 KiB)

osx client paint boxes - look like on fedora

totaam · 2015-01-23T20:01:37Z

2015-01-23 20:01:37: afarr uploaded file `ticket760_opengl-paint-boxes_windows8534.png` (290.5 KiB)

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

totaam · 2015-01-23T20:02:39Z

2015-01-23 20:02:39: afarr uploaded file `ticket760_opengl-paint-boxes_windows8534_All-Delta_pic2.png` (288.4 KiB)

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

totaam · 2015-01-23T20:14:45Z

2015-01-23 20:14:45: afarr commented

OSX client seems to behave as expected:

[[BR]]

[[Image(ticket760_opengl-paint-boxes_osx8534.png)]]

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

[[BR]]

[[Image( ticket760_opengl-paint-boxes_windows8534.png)]]

delta (delta always seems to be png):

[[BR]]

[[Image( ticket760_opengl-paint-boxes_windows8534_All-Delta_pic2.png)]]

[[BR]]

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.

totaam · 2015-01-23T20:23:39Z

2015-01-23 20:23:39: afarr uploaded file `ticket760_opengl-paint-boxes_windows8534_All-Delta.png` (398.7 KiB)

windows client with apparently all delta - full size

totaam · 2015-01-24T07:22:00Z

2015-01-24 07:22:00: totaam commented

While windows clients seem to be encoding the entire screen uniformly (perhaps they are?)
[[BR]]
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.

[[BR]]

delta (delta always seems to be png):
[[BR]]
delta can be used by all rgb24, rgb32 and png.
With a terminal it's quite easy to trigger rgb24+delta paints.

[[BR]]

One interesting note - the windows paint boxes only seem to have frames on the left and lower edges of the application window
[[BR]]
One way to confirm that would be to use -d paint and then visually reconcile the output with the rectangles painted on screen...

totaam · 2015-02-11T01:33:31Z

2015-02-11 01:33:31: afarr commented

Testing with windows 8.1 client 0.15.0 8647 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

totaam · 2015-02-11T01:34:29Z

2015-02-11 01:34:29: afarr uploaded file `ticket760_4K_youtube-paint-boxes-not-clear.PNG` (960.1 KiB)

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

totaam · 2015-02-11T01:35:16Z

2015-02-11 01:35:16: afarr uploaded file `ticket760_screenshot_left-and-lower-edge-boxes.PNG` (577.0 KiB)

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

totaam · 2015-02-11T01:36:01Z

2015-02-11 01:36:01: afarr uploaded file `ticket760-d_paint2.txt` (3740.1 KiB)

Overly verbose windows client logs with -d paint

totaam · 2015-02-11T03:51:18Z

2015-02-11 03:51:18: totaam changed status from assigned to new

totaam · 2015-02-11T03:51:18Z

2015-02-11 03:51:18: totaam changed owner from afarr to totaam

totaam · 2015-02-11T03:51:18Z

2015-02-11 03:51:18: totaam commented

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..)

totaam · 2015-05-01T04:09:57Z

2015-05-01 04:09:57: antoine changed owner from totaam to afarr

totaam · 2015-05-01T04:09:57Z

2015-05-01 04:09:57: antoine commented

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

totaam · 2015-05-15T01:42:21Z

2015-05-15 01:42:21: afarr uploaded file `ticket760_r9365_client-d_paint.txt` (371.6 KiB)

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

totaam · 2015-05-15T03:51:29Z

2015-05-15 03:51:29: antoine changed status from new to assigned

totaam · 2015-05-15T03:51:29Z

2015-05-15 03:51:29: antoine changed owner from afarr to antoine

totaam · 2015-05-15T03:51:29Z

2015-05-15 03:51:29: antoine commented

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.

totaam · 2015-05-19T13:59:10Z

2015-05-19 13:59:10: antoine commented

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.

totaam · 2015-05-23T11:26:51Z

2015-05-23 11:26:51: antoine changed status from assigned to new

totaam · 2015-05-23T11:26:51Z

2015-05-23 11:26:51: antoine changed owner from antoine to afarr

totaam · 2015-05-23T11:26:51Z

2015-05-23 11:26:51: antoine commented

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

totaam · 2015-05-28T02:10:44Z

2015-05-28 02:10:44: afarr commented

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?

totaam · 2015-05-28T05:06:17Z

2015-05-28 05:06:17: antoine commented

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.

totaam · 2015-05-29T02:50:54Z

2015-05-29 02:50:54: afarr commented

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.

totaam · 2015-06-02T00:04:05Z

2015-06-02 00:04:05: afarr commented

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.

totaam · 2015-06-02T00:14:54Z

2015-06-02 00:14:54: afarr commented

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.

totaam · 2015-06-02T05:43:42Z

2015-06-02 05:43:42: antoine commented

Testing with osx & win32 0.15.0 ..
[[BR]]
As per comment:22 and again in comment:24: the fix is in trunk, not in 0.15 or older.

[[BR]]

I also notice that there seems to be an upper limit to what I can do going crazy with the border settings
[[BR]]
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.

totaam · 2015-08-27T02:54:56Z

2015-08-27 02:54:56: afarr commented

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).

totaam · 2015-08-27T05:36:58Z

2015-08-27 05:36:58: antoine commented

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

Can I close this ticket?

[[BR]]

I can't seem to change the border size with border=4 v. border=43 either server or client side (or both).
[[BR]]
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 ...

totaam · 2015-09-18T00:54:24Z

2015-09-18 00:54:24: afarr changed status from new to closed

totaam · 2015-09-18T00:54:24Z

2015-09-18 00:54:24: afarr set resolution to fixed

totaam · 2015-09-18T00:54:24Z

2015-09-18 00:54:24: afarr commented

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

I'll close this myself.

totaam · 2016-02-25T08:32:44Z

2016-02-25 08:32:44: antoine commented

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

totaam closed this as completed Sep 18, 2015

totaam mentioned this issue Jan 23, 2023

Subpar performance when running gvim or emacs #670

Closed

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

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

Comments

totaam commented Dec 9, 2014

2014-12-09 23:38:47: afarr created the issue

totaam commented Dec 10, 2014

2014-12-10 00:07:15: antoine changed status from new to assigned

totaam commented Dec 10, 2014

2014-12-10 00:07:15: antoine commented

totaam commented Dec 26, 2014

2014-12-26 07:41:03: antoine changed status from assigned to new

totaam commented Dec 26, 2014

2014-12-26 07:41:03: antoine changed owner from antoine to afarr

totaam commented Dec 26, 2014

2014-12-26 07:41:03: antoine commented

totaam commented Dec 26, 2014

2014-12-26 07:41:28: antoine uploaded file box-colors.png (371.6 KiB)

totaam commented Dec 28, 2014

2014-12-28 09:36:37: totaam commented

totaam commented Dec 28, 2014

2014-12-28 10:16:52: totaam changed title from Would it be possible to have a debug flag added that would allow for subregion color coding according to encodings, quality, speed, etc? to debug option for subregion color coding according to encodings, quality, speed, etc?

totaam commented Dec 28, 2014

2014-12-28 10:16:52: totaam commented

totaam commented Jan 17, 2015

2015-01-17 02:47:19: afarr commented

totaam commented Jan 17, 2015

2015-01-17 02:53:51: totaam commented

totaam commented Jan 23, 2015

2015-01-23 02:17:25: afarr changed status from new to assigned

totaam commented Jan 23, 2015

2015-01-23 02:17:25: afarr commented

totaam commented Jan 23, 2015

2015-01-23 03:14:35: totaam commented

totaam commented Jan 23, 2015

2015-01-23 19:58:57: afarr commented

totaam commented Jan 23, 2015

2015-01-23 20:00:32: afarr uploaded file ticket760_opengl-paint-boxes_osx8534.png (855.0 KiB)

totaam commented Jan 23, 2015

2015-01-23 20:01:37: afarr uploaded file ticket760_opengl-paint-boxes_windows8534.png (290.5 KiB)

totaam commented Jan 23, 2015

2015-01-23 20:02:39: afarr uploaded file ticket760_opengl-paint-boxes_windows8534_All-Delta_pic2.png (288.4 KiB)

totaam commented Jan 23, 2015

2015-01-23 20:14:45: afarr commented

totaam commented Jan 23, 2015

2015-01-23 20:23:39: afarr uploaded file ticket760_opengl-paint-boxes_windows8534_All-Delta.png (398.7 KiB)

totaam commented Jan 24, 2015

2015-01-24 07:22:00: totaam commented

totaam commented Feb 11, 2015

2015-02-11 01:33:31: afarr commented

totaam commented Feb 11, 2015

2015-02-11 01:34:29: afarr uploaded file ticket760_4K_youtube-paint-boxes-not-clear.PNG (960.1 KiB)

totaam commented Feb 11, 2015

2015-02-11 01:35:16: afarr uploaded file ticket760_screenshot_left-and-lower-edge-boxes.PNG (577.0 KiB)

totaam commented Feb 11, 2015

2015-02-11 01:36:01: afarr uploaded file ticket760-d_paint2.txt (3740.1 KiB)

totaam commented Feb 11, 2015

2015-02-11 03:51:18: totaam changed status from assigned to new

totaam commented Feb 11, 2015

2015-02-11 03:51:18: totaam changed owner from afarr to totaam

totaam commented Feb 11, 2015

2015-02-11 03:51:18: totaam commented

totaam commented May 1, 2015

2015-05-01 04:09:57: antoine changed owner from totaam to afarr

totaam commented May 1, 2015

2015-05-01 04:09:57: antoine commented

totaam commented May 15, 2015

2015-05-15 01:42:21: afarr uploaded file ticket760_r9365_client-d_paint.txt (371.6 KiB)

totaam commented May 15, 2015

2015-05-15 03:51:29: antoine changed status from new to assigned

totaam commented May 15, 2015

2015-05-15 03:51:29: antoine changed owner from afarr to antoine

totaam commented May 15, 2015

2015-05-15 03:51:29: antoine commented

totaam commented May 19, 2015

2015-05-19 13:59:10: antoine commented

totaam commented May 23, 2015

2015-05-23 11:26:51: antoine changed status from assigned to new

totaam commented May 23, 2015

2015-05-23 11:26:51: antoine changed owner from antoine to afarr

totaam commented May 23, 2015

2014-12-26 07:41:28: antoine uploaded file `box-colors.png` (371.6 KiB)

2015-01-23 20:00:32: afarr uploaded file `ticket760_opengl-paint-boxes_osx8534.png` (855.0 KiB)

2015-01-23 20:01:37: afarr uploaded file `ticket760_opengl-paint-boxes_windows8534.png` (290.5 KiB)

2015-01-23 20:02:39: afarr uploaded file `ticket760_opengl-paint-boxes_windows8534_All-Delta_pic2.png` (288.4 KiB)

2015-01-23 20:23:39: afarr uploaded file `ticket760_opengl-paint-boxes_windows8534_All-Delta.png` (398.7 KiB)

2015-02-11 01:34:29: afarr uploaded file `ticket760_4K_youtube-paint-boxes-not-clear.PNG` (960.1 KiB)

2015-02-11 01:35:16: afarr uploaded file `ticket760_screenshot_left-and-lower-edge-boxes.PNG` (577.0 KiB)

2015-02-11 01:36:01: afarr uploaded file `ticket760-d_paint2.txt` (3740.1 KiB)

2015-05-15 01:42:21: afarr uploaded file `ticket760_r9365_client-d_paint.txt` (371.6 KiB)