#927 closed task (fixed)
review our use of memoryview_to_bytes
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.16 |
Component: | core | Version: | 0.15.x |
Keywords: | Cc: |
Description
As per #926, this can be expensive.
We call it from the following codepaths:
- non-openl rendering and icon code (cairo and pixmap): don't care
- opengl without zero copy upload: don't care
- the window source's delta
rgb_encode
at level=0compressed_wrapper
mmap_write
- pillow encoder
- proxy encoder
The difficulty is in figuring out what data types are going to come through all these codepaths, as this will depend on the type of server (shadow, standard, proxy..), the type of codecs and csc modules available, etc...
Change History (4)
comment:1 Changed 7 years ago by
Owner: | changed from Antoine Martin to Smo |
---|
comment:2 Changed 7 years ago by
Owner: | changed from Smo to Antoine Martin |
---|
Haven't noticed any ill effects from this change is there anything else we can do to make sure?
comment:3 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
This was mostly a FYI. Closing.
(having tickets for the automated tests would really help)
comment:4 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/927
Note: See
TracTickets for help on using
tickets.
done in r10986
@smo: if I've done this right (and I believe I have - it is small after all), aside from making the code a bit cleaner, we may get a small performance increase in some cases by not making an extra copies unnecessarily (pillow and the compressors can take a "buffer" as input and we no longer convert that to bytes), if I've done this wrong we could get all sorts of memory corruption and weird behaviour... which should cause random failures in the automated perf test.
If things don't get any worse, I think we can close this.