You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow up from #465, we should provide an optional image wrapper function to restride and xor in one pass. (and maybe even do the byte swapping to RGB?)
This would be used by the rgb_encode to speed things up significantly, especially when we can / should xor the whole image buffer (ie: when shadowing a display and using a non-video encoding).
Bonus points if we can take advantage of realloc to do things in-place. Though I doubt this would be useful for the common case: when using an xshm image, we may not be allowed to write to it? or if we are, it would require extra work to ensure it does not get freed until after the packet has been sent... (or we could just force compression to ensure the buffer is consumed before we free the image)
Also, it's a shame that we cannot feed the data to lz4 one image row at a time, or we could then even combine restriding, xor, byteswapping and compression in one pass!
Another idea that just came up: the ability to provide the target buffer as an optional argument could be used with encoders like nvenc to copy directly into their input buffer as part of the restriding.
The text was updated successfully, but these errors were encountered:
memoryview was enabled by default for 0.16 in r9223.
The restride is now done as an optional method on the image wrapper class, only implemented for the ximage wrapper (also used by xshm image wrapper): done in r9235.
Looking at the other codepaths, they're all either fairly uncommon or cheap enough already. The only case that may warrant more work is the shadow servers: those don't use the x11 image wrapper and call get_rgb_rawdata.
Follow up from #465, we should provide an optional image wrapper function to restride and xor in one pass. (and maybe even do the byte swapping to RGB?)
This would be used by the
rgb_encode
to speed things up significantly, especially when we can / should xor the whole image buffer (ie: when shadowing a display and using a non-video encoding).Bonus points if we can take advantage of
realloc
to do things in-place. Though I doubt this would be useful for the common case: when using an xshm image, we may not be allowed to write to it? or if we are, it would require extra work to ensure it does not get freed until after the packet has been sent... (or we could just force compression to ensure the buffer is consumed before we free the image)Also, it's a shame that we cannot feed the data to lz4 one image row at a time, or we could then even combine restriding, xor, byteswapping and compression in one pass!
Another idea that just came up: the ability to provide the target buffer as an optional argument could be used with encoders like nvenc to copy directly into their input buffer as part of the restriding.
The text was updated successfully, but these errors were encountered: