Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
totaam opened this issue Dec 9, 2014 · 55 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Dec 9, 2014

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
Copy link
Collaborator Author

totaam commented Dec 10, 2014

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

@totaam
Copy link
Collaborator Author

totaam commented Dec 10, 2014

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:

@totaam
Copy link
Collaborator Author

totaam commented Dec 26, 2014

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

@totaam
Copy link
Collaborator Author

totaam commented Dec 26, 2014

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

@totaam
Copy link
Collaborator Author

totaam commented Dec 26, 2014

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


_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
Copy link
Collaborator Author

totaam commented Dec 26, 2014

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

shows the box paint in use with youtube
box-colors.png

@totaam
Copy link
Collaborator Author

totaam commented Dec 28, 2014

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

totaam commented Dec 28, 2014

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
Copy link
Collaborator Author

totaam commented Jan 17, 2015

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
Copy link
Collaborator Author

totaam commented Jan 17, 2015

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
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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
ticket760_opengl-paint-boxes_osx8534.png

@totaam
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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
ticket760_opengl-paint-boxes_windows8534.png

@totaam
Copy link
Collaborator Author

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)

opengl paint boxes on windows client shows only one encoding - delta here
ticket760_opengl-paint-boxes_windows8534_All-Delta_pic2.png

@totaam
Copy link
Collaborator Author

totaam commented Jan 23, 2015

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
Copy link
Collaborator Author

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)

windows client with apparently all delta - full size
ticket760_opengl-paint-boxes_windows8534_All-Delta.png

@totaam
Copy link
Collaborator Author

totaam commented Jan 24, 2015

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
Copy link
Collaborator Author

totaam commented Feb 11, 2015

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
Copy link
Collaborator Author

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)

window on 4K monitor, opengl paint box markers only on edges of window
ticket760_4K_youtube-paint-boxes-not-clear.PNG

@totaam
Copy link
Collaborator Author

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)

small window, with delta and general encoding in tandem - only showing on edges
ticket760_screenshot_left-and-lower-edge-boxes.PNG

@totaam
Copy link
Collaborator Author

totaam commented Feb 11, 2015

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
Copy link
Collaborator Author

totaam commented Feb 11, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented Feb 11, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented Feb 11, 2015

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
Copy link
Collaborator Author

totaam commented May 1, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented May 1, 2015

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
Copy link
Collaborator Author

totaam commented May 15, 2015

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
Copy link
Collaborator Author

totaam commented May 15, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented May 15, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented May 15, 2015

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
Copy link
Collaborator Author

totaam commented May 19, 2015

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
Copy link
Collaborator Author

totaam commented May 23, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented May 23, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented May 23, 2015

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
Copy link
Collaborator Author

totaam commented May 28, 2015

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
Copy link
Collaborator Author

totaam commented May 28, 2015

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
Copy link
Collaborator Author

totaam commented May 29, 2015

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
Copy link
Collaborator Author

totaam commented Jun 2, 2015

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
Copy link
Collaborator Author

totaam commented Jun 2, 2015

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
Copy link
Collaborator Author

totaam commented Jun 2, 2015

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
Copy link
Collaborator Author

totaam commented Aug 27, 2015

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
Copy link
Collaborator Author

totaam commented Aug 27, 2015

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
Copy link
Collaborator Author

totaam commented Sep 18, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented Sep 18, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented Sep 18, 2015

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


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

I'll close this myself.

@totaam totaam closed this as completed Sep 18, 2015
@totaam
Copy link
Collaborator Author

totaam commented Feb 25, 2016

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


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant