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

[totaam]

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?

[totaam]

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

[totaam]

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: #478, #679 (linking it back here)

[totaam]

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

[totaam]

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

[totaam]

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-26 07:41:28: antoine uploaded file box-colors.png (371.6 KiB)

shows the box paint in use with youtube

[totaam]

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-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-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-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-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-23 02:17:25: afarr changed status from new to assigned

[totaam]

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-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-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-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-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-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-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-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-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-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-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-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-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-11 03:51:18: totaam changed status from assigned to new

[totaam]

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

[totaam]

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-01 04:09:57: antoine changed owner from totaam to afarr

[totaam]

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-07 23:24:44: afarr commented

---

Yes... testing with 0.15.0 9202 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 9202 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?

[totaam]

2015-05-11 17:31:48: antoine commented

---

Yes, running with an intel graphics card, but overriding with --opengl=on. [[BR]] 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 9303)

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)

[totaam]

2015-05-12 06:46:25: antoine commented

---

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

[totaam]

2015-05-12 06:58:06: antoine commented

---

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

[totaam]

2015-05-15 01:41:03: afarr commented

---

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.

[totaam]

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-15 03:51:29: antoine changed status from new to assigned

[totaam]

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

[totaam]

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-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-23 11:26:51: antoine changed status from assigned to new

[totaam]

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

[totaam]

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