xpra icon
Bug tracker and wiki

Opened 9 months ago

Closed 9 months ago

#2077 closed enhancement (fixed)

_XPRA_QUALITY attribute

Reported by: Nathan Hallquist Owned by: Nathan Hallquist
Priority: minor Milestone: 2.5
Component: encodings Version: 2.4.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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.

Attachments (1)

b.patch (546 bytes) - added by Nathan Hallquist 9 months ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 9 months ago by Antoine Martin

Description: modified (diff)
Priority: majorminor
Status: newassigned

comment:2 Changed 9 months ago by Antoine Martin

Owner: changed from Antoine Martin to Nathan Hallquist
Status: assignednew

Please try r21238 or later.

comment:3 Changed 9 months ago by 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.

Changed 9 months ago by Nathan Hallquist

Attachment: b.patch added

comment:4 Changed 9 months ago by 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

comment:5 Changed 9 months ago by Nathan Hallquist

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

comment:6 in reply to:  5 ; Changed 9 months ago by 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.

comment:7 in reply to:  6 Changed 9 months ago by 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.

comment:8 Changed 9 months ago by 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'}

comment:9 Changed 9 months ago by Antoine Martin

Owner: changed from Nathan Hallquist to Antoine Martin
Status: newassigned

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.

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:10 Changed 9 months ago by 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).

comment:11 Changed 9 months ago by 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.

comment:12 Changed 9 months ago by Antoine Martin

Owner: changed from Antoine Martin to Nathan Hallquist
Status: assignednew

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.

comment:13 in reply to:  12 Changed 9 months ago by 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?

Last edited 9 months ago by Nathan Hallquist (previous) (diff)

comment:14 Changed 9 months ago by 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?

comment:15 Changed 9 months ago by 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.

comment:16 Changed 9 months ago by 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)

comment:17 Changed 9 months ago by 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.

comment:18 Changed 9 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.