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
Reported in version: 2.0.9 Reported for operating system, platform: All, All
Comments on the original bug report:
On 2019-02-27 18:01:04 +0000, Dmitry Gapkalov wrote:
Created attachment 3659
patch
remove excess allocations and memory copying while SDL_CreateTextureFromSurface for s/w render in situation while texture and surface format is equal.
case:
load gfx file to surface
create texture from surface
free surface
use texture for blit to screen
basic idea in sharing pixel data between surface and texture in situation while format of surface and texture are equal.
On 2019-07-30 17:49:39 +0000, Ryan C. Gordon wrote:
(Sorry if you get several emails like this, we're marking a bunch of bugs.)
We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.
Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.
If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.
--ryan.
On 2019-08-19 17:38:41 +0000, Moritz Bruder wrote:
It would probably make more sense to provide this a function for the software back-end that falls back to something like:
SDL_Texture texture = SDL_CreateTexture(renderer, surface);
SDL_FreeSurface(surface);
return texture;
On the software back-end it moves the pixel data and the other stuff to the texture and overwrites and frees the surface. Basically, the important stuff gets moved without expensive copies. I wouldn't share any of that without explicitly stating it. Otherwise, that might lead to annoying behavior and unexpected side effects.
On 2019-09-20 20:47:39 +0000, Ryan C. Gordon wrote:
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).
As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!
Thanks,
--ryan.
On 2019-09-20 20:48:39 +0000, Ryan C. Gordon wrote:
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).
As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!
Thanks,
--ryan.
On 2019-10-27 05:06:56 +0000, Ryan C. Gordon wrote:
I agree with Moritz, we should probably add a function named something like SDL_ConvertSurfaceToTexture() where it explicitly destroys the surface, possibly stealing its internal data for the new texture without copying it.
As such, I'm removing the target-2.0.12 keyword from this bug, so we can explore this in the (near?) future.
--ryan.
On 2019-11-01 17:40:06 +0000, Sam Lantinga wrote:
Agreed.
The text was updated successfully, but these errors were encountered:
SDL_CreateTextureFromSurface() will already directly upload the pixels from surfaces with matching formats, so this is essentially doing what you're asking for here.
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: 2.0.9
Reported for operating system, platform: All, All
Comments on the original bug report:
On 2019-02-27 18:01:04 +0000, Dmitry Gapkalov wrote:
On 2019-07-30 17:49:39 +0000, Ryan C. Gordon wrote:
On 2019-08-19 17:38:41 +0000, Moritz Bruder wrote:
On 2019-09-20 20:47:39 +0000, Ryan C. Gordon wrote:
On 2019-09-20 20:48:39 +0000, Ryan C. Gordon wrote:
On 2019-10-27 05:06:56 +0000, Ryan C. Gordon wrote:
On 2019-11-01 17:40:06 +0000, Sam Lantinga wrote:
The text was updated successfully, but these errors were encountered: