| Summary: | SDL_Texture should be passed as a const pointer | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Mika Pi <te.anton> |
| Component: | render | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED INVALID | QA Contact: | Sam Lantinga <slouken> |
| Severity: | trivial | ||
| Priority: | P2 | CC: | amaranth72, icculus |
| Version: | HG 2.1 | ||
| Hardware: | All | ||
| OS: | All | ||
Those functions may modify some internal state stored in the texture's struct, so the external API can't have a const pointer argument without lying about what it does.
> Those functions may modify some internal state stored in the texture's struct
Yes, and in fact, they do.
--ryan.
If you read from memory, the PC states modifies it's internal state. Bits get moved from DDRAM to the CPU cache. That you said is not an argument. It's may be good to lie in this situation. The data pointed to during this function call is modified during this function call. It’s not constant. So we don’t label it as const. This is not a bug. I did not look in the code but I assume SDL_Texture has some pointer to internal state of GPU or something, and texture from RAM is getting moved to GPU memory, so next time you call SDL_RenderCopy it runs faster? Is it some sort of cache? If it cache it is better to make texture pointer const and internally in SDL_RenderCopy implementation do cast to non-const. The struct has a pointer to the GPU data, but it also has fields for various other things which are modified during RenderCopy: https://hg.libsdl.org/SDL/file/0280fd2d02ca/src/render/SDL_sysrender.h#l42 (The actual modifications happen both in the high level platform-agnostic RenderCopy code, and in the platform implementations that RenderCopy calls into.) Since the contents of the struct are modified by RenderCopy, it's not marked as const. If you didn't look at SDL's code beforehand, is there a specific reason for wanting it marked as const other than an assumption about the source code? Semantically SDL_RenderCopy takes data form the texture and renders in in the renderer, semantically texture is not modified, the function SDL_RenderCopy can do something for performance saike (eg. caching), but for the end user of API it should be invisible. (In reply to Anton Te from comment #7) > Semantically SDL_RenderCopy takes data form the texture and renders in in > the renderer, semantically texture is not modified, the function > SDL_RenderCopy can do something for performance saike (eg. caching), but for > the end user of API it should be invisible. It’s already opaque data to the API user anyhow, but again, the data is not const, so we will not be marking it—incorrectly—as const. This is a final answer on this. |
For example signature for SDL_RenderCopy should look like following: int SDL_RenderCopy(SDL_Renderer* renderer, const SDL_Texture* texture, const SDL_Rect* srcrect, const SDL_Rect* dstrect);