_XPRA_QUALITY attribute

[Nathan Hallquist]

In ticket:2056#comment:12 Antoine suggested implementing an X-window property called _XPRA_QUALITY for setting the encoder quality on a per-window basis.

This ticket which I am opening is to request that enhancement. I have already implemented support for setting this property in some OpenGL software (from my employer). To do this I used the XA_INTEGER type. I am ready to test _XPRA_QUALITY as soon as it is added.

[Antoine Martin]

Please try r21238 or later.

[Nathan Hallquist]

With the attached patch it works. I haven't look through XPRA to figure out what the difference between "get" and "get_property" is.

[Antoine Martin]

I don't really understand why you needed that patch (what did you see?) - in fact, I don't understand how it could possibly work with that patch and without r21244.
In any case, r21243 merges that change and also tidies up the code.

How I tested:

XPRA_WINDOW_PROPERTIES_DEBUG=quality python2 /usr/bin/xpra --start=xterm --no-daemon -d compress

(note: it may take up to a second for the new quality setting to take effect)

Verified the value is set correctly with:

$ xpra info | grep quality-hint
client.window.1.property.quality-hint=-1

[Nathan Hallquist]

With just "get" it always returned a "-1". With "get_property" everything worked fine. I'll try your updated one though.

[Nathan Hallquist]

It still works. Now the value "0" doesn't work. That's not a big deal though, I'll let our UI people know that the slider should range from 1 to 100.

Thanks!

Replying to Nathan Hallquist:

With just "get" it always returned a "-1". With "get_property" everything worked fine. I'll try your updated one though.

[Nathan Hallquist]

It seems to register changes in the slider more rapidly than before, but it's hard for me to be certain.

Replying to Nathan Hallquist:

It still works. Now the value "0" doesn't work. That's not a big deal though, I'll let our UI people know that the slider should range from 1 to 100.

Thanks!

Replying to Nathan Hallquist:

With just "get" it always returned a "-1". With "get_property" everything worked fine. I'll try your updated one though.

[Nathan Hallquist]

Now I have one other small problem. Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.

We *can* pass in the relatively coordinates of the video region if that helps. I have both quality set to auto and encoder set to auto and I've not disabled scroll encoding.

Here's a compress log of me triggering a menu:

2018-12-19 09:40:17,622 compress:   0.3ms for  226x174  pixels at    0,0    for wid=64    using      jpeg with ratio   1.1%  (  153KB to     1KB), sequence     1, client_options={u'quality': 0}
2018-12-19 09:40:17,634 compress:   0.2ms for   72x26   pixels at  127,0    for wid=3     using     rgb24 with ratio  15.7%  (    7KB to     1KB), sequence   186, client_options={'bucket': 2, 'lz4': 1, 'store': 373, 'rgb_format': 'BGRX'}
2018-12-19 09:40:17,777 compress:   2.8ms for  226x174  pixels at    0,0    for wid=64    using      webp with ratio   7.7%  (  153KB to    11KB), sequence     2, client_options={u'quality': 100, u'rgb_format': 'BGRX'}
2018-12-19 09:40:18,383 compress:   0.1ms for   72x26   pixels at  127,0    for wid=3     using     rgb24 with ratio  14.4%  (    7KB to     1KB), sequence   187, client_options={'delta': 373, 'bucket': 2, 'lz4': 1, 'store': 375, 'rgb_format': 'BGRX'}
2018-12-19 09:40:18,754 compress:   0.5ms for  221x446  pixels at    0,0    for wid=65    using      jpeg with ratio   0.9%  (  385KB to     3KB), sequence     1, client_options={u'quality': 0}
2018-12-19 09:40:18,779 compress:   0.1ms for   82x26   pixels at  240,0    for wid=3     using     rgb24 with ratio   0.6%  (    8KB to     0KB), sequence   188, client_options={'delta': 343, 'bucket': 3, 'lz4': 1, 'store': 377, 'rgb_format': 'BGRX'}

[Antoine Martin]

Now I have one other small problem. Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.

Yes, that's a bug. I saw it, I'll try to find the time for it today.

We *can* pass in the relatively coordinates of the video region if that helps.

That always helps, there's a dbus api for that: #1401, #1060, #1295
We could also support a _XPRA_VIDEO_REGION window property if that helps.

I have both quality set to auto and encoder set to auto and I've not disabled scroll encoding.

Good.

[Nathan Hallquist]

I would prefer to use x window properties because people here already know how to do that.

That said, we could probably use dbus if necessary. Practically, using dbus would mean I would have to learn how to use dbus myself and then show the UI people; a display property would certainly be simpler for me. (I already did this process for display properties; I learned how to program them from the documentation and then I showed the UI team).

[Antoine Martin]

I would prefer to use x window properties because people here already know how to do that.

Then please create a new ticket for this feature request.

[Antoine Martin]

Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.

This is fixed in r21250, see commit message for details. You should now also be able to use the full range, from 0 to 100 for quality and speed settings.

[Nathan Hallquist]

Replying to Antoine Martin:

Even with _XPRA_QUALITY set to "99" the menus always jump in blurry (so blurry as to be useless) and then they settle to lossless. Is there a setting/way to fix this.

This is fixed in r21250, see commit message for details. You should now also be able to use the full range, from 0 to 100 for quality and speed settings.

Thanks for fixing this!

When you said, "that is a bug" I may have misunderstood you. I thought you were talking about the blurry menu issue. Are the blurry menus caused by a overly-large video region, perhaps?

[Antoine Martin]

I thought you were talking about the blurry menu issue. Are the blurry menus caused by a overly-large video region, perhaps?

I'm pretty sure the blurry menus were caused by the quality being set to zero due to the invalid clamping which is fixed in r21250.
Menus have their own windows so they should not be affected by video regions.
Is it not fixed?

[Nathan Hallquist]

I thought you meant this was in response to my comment that we were going to have to change our sliders so that they go from 1 to 99. This is what happens when I think I understand things.

Anyway, you are right. That fixed it! Thank you.

[Nathan Hallquist]

When I adjust the _XPRA_QUALITY attribute it does not seem to take effect until I let my program sit idle for a while. I suspect XPRA is not updating the quality in the nvenc encoder until it recycles the context. (I haven't dug into this too deeply yet, but I can if requested)

[Antoine Martin]

When I adjust the _XPRA_QUALITY attribute it does not seem to take effect until I let my program sit idle for a while.

Fixed in r21259, see ticket:2022#comment:47.

[Antoine Martin]

Feel free to re-open if you still have issues.

[migration script]

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