| Summary: | STREAMING Texture, UpdateTexture not compatible with LockTexture() | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Sylvain <sylvain.becker> |
| Component: | render | Assignee: | Sylvain <sylvain.becker> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | don't know | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
testcase
patch patch patch v2 |
||
Created attachment 3081 [details]
patch
Small patch could be redirect SDL_UpdateTexture() to a combination of LockTexture() / SDL_memcpy() / SDL_UnlockTexture().
Created attachment 3082 [details]
patch
patch
Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release. Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon. If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks. Thanks! --ryan. This is already fixed, thanks! Hi, It seems to me it's not fixed. tested with current head, on linux, with the current test case: with the software renderer, the image is drawn in background. with other renderer, there is a black background. The patch seem to works, but I think it's not correct, and maybe there are more optimized things to do. the streaming texture can be: - normal: (it has one of the renderer format or not) - need a conversion. (then has a "native" texture field). Most renderers implement streaming access by adding Lock/Unlock texture functions which are an intermediate storing buffer before access. Just wondering if those implementation could be simply removed and replaced by a dummy use of the "native" texture field (with the same format as the user texture). Let's revisit this after 2.0.10. This is somewhat by design, for efficiency. Let's see if there is a solution that doesn't reduce performance by introducing additional copy operations. Created attachment 3837 [details]
patch v2
I agree.
So either UpdateTexture updates the streaming buffer and then, it's consistent with Lock/UnlockTexture, or not, and then, it's faster.
Here's a modified patch if needed (it seems to affect normal texture, and native, but not yuv).
But, it's probably better to keep the actual UpdateTexture so it's faster.
If user needs to update the entire streaming buffer, it can still be done by Locking the buffer.
|
Created attachment 3080 [details] testcase When using textures created with SDL_TEXTUREACCESS_STREAMING flags, SDL_UpdateTexture() and SDL_LockTexture() aren't updating the same internal memory. If you initialize first your texture with SDL_UpdateTexture(), you won't get the pixels back by using SDL_LockTexture(). It would work with software renderer, but not with opengl, nor opengles2. here's a testcase