See wiki/CSC/Performance where I have added results for trunk. swscale has improved a lot since we last ran the tests, but the cython version has regressed.
First problem is that you have to select the correct device... r10084 fixes that code, r10085 backports it.
Then after updating the wiki performance page above, it seems that the regression is not new: it happened between 0.14.x and 0.15.x (halved).
The other problem is our calls to memoryview_to_bytes
(new related ticket: #927), which is a nice utility function, but too coarse: in some cases we can handle the data without converting it to bytes, and we should. r10087 + r10089 fix that for the opencl csc, backport in r10088 + r10090.
@smo: re-assigning to you so you can take a look at the performance data which might interest you, in particular just how fast swscale has become - but opencl isn't bad either...
There has been many updates over this time period to Cython do you think this might be the regression we are seeing or is that totally unrelated?
@smo: regression? csc_opencl is pure python...
And with the fixes above, the csc_opencl performance is as good as it was before.
Sorry I misunderstood. Ignore my last comment.
I will run some more of these tests to make sure its still about the same as your tests.
Should I update that table with my test data as well?
@smo: we should be recording as much data as we can, so that if a regression is introduced like the one above, we catch it before the release... not 2 releases later! (it wasn't too bad because we don't use csc_opencl, but a similar issue with csc_swscale would be costly!)
Raising: see ticket:973#comment:2
9 months... please just make some quick measurements and close.
When I talked to you we agreed we weren't concerned with this module anymore as libyuv works very well.
Closing this for now without measurements. Will reopen if you find it absolutely necessary.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/926