We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4762

Summary: SDL_RenderDraw* / SDL_RenderFill* functions - wrong colour with direct3d render driver
Product: SDL Reporter: b7874409
Component: renderAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: icculus, sylvain.becker
Version: 2.0.10Keywords: target-2.0.12
Hardware: x86   
OS: Windows 7   

Description b7874409 2019-08-14 10:02:30 UTC
SDL_RenderDraw* / SDL_RenderFill* functions - wrong colour with direct3d render driver

SDL_RenderDraw* and SDL_RenderFill* functions use the wrong colour or alpha values with the direct3d render driver depending on the presence of other seemingly unrelated functions

Minimal example code showing the problem :

#include <SDL.h>
#include <SDL_ttf.h>

int main(int argc, char* argv[])
{
	SDL_Window* win;
	SDL_Renderer* ren;
	TTF_Font* font;
	SDL_Event event;
	int quit=0;
	SDL_Rect rect={0, 0, 100, 100};
	SDL_Surface* text_surf;
	SDL_Texture* text_tex;
	/*Changing the font colour changes the colour of the rectangle*/
	SDL_Color font_col={150, 150, 150, 255}; /*grey*/
	SDL_Rect text_dst={0, 200, 0, 0};

	SDL_Init(SDL_INIT_VIDEO);
	win=SDL_CreateWindow("test", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
	/*The problem is not present with the opengl render driver*/
	SDL_SetHint(SDL_HINT_RENDER_DRIVER, "direct3d");
	ren=SDL_CreateRenderer(win, -1, SDL_RENDERER_ACCELERATED|SDL_RENDERER_PRESENTVSYNC);
	/*Setting the blend mode to SDL_BLENDMODE_BLEND results in the rectangle having incorrect alpha*/
	SDL_SetRenderDrawBlendMode(ren, SDL_BLENDMODE_NONE);
	TTF_Init();
	font=TTF_OpenFont("C:\\Windows\\Fonts\\Arial.ttf", 22);

	while(!quit)
	{
		while(SDL_PollEvent(&event)) if(event.type==SDL_QUIT) quit=1;

		SDL_SetRenderDrawColor(ren, 255, 255, 255, 255); /*white*/
		SDL_RenderClear(ren);

		SDL_SetRenderDrawColor(ren, 255, 0, 0, 255); /*red*/
		SDL_RenderFillRect(ren, &rect);

		text_surf=TTF_RenderText_Blended(font, "test", font_col);
		/*The problem is still present when using SDL_CreateRGBSurfaceWithFormat instead of TTF_RenderText_Blended*/
		/*text_surf=SDL_CreateRGBSurfaceWithFormat(0, 20, 20, 32, SDL_PIXELFORMAT_RGBA32);*/
		text_tex=SDL_CreateTextureFromSurface(ren, text_surf);
		text_dst.w=text_surf->w;
		text_dst.h=text_surf->h;
		SDL_FreeSurface(text_surf);
		SDL_RenderCopy(ren, text_tex, NULL, &text_dst);
		/*The problem is not present when calling SDL_RenderDraw* or SDL_RenderFill* after SDL_RenderCopy and before SDL_DestroyTexture*/
		/*SDL_RenderDrawLine(ren, 150, 50, 200, 50);*/
		SDL_DestroyTexture(text_tex);

		SDL_RenderPresent(ren);
	}

	TTF_CloseFont(font);
	SDL_DestroyRenderer(ren);
	SDL_DestroyWindow(win);
	TTF_Quit();
	SDL_Quit();

    return 0;
}


As can be seen in the code above :
- Changing the font colour changes the colour of the rectangle
- The problem is not present with the opengl render driver
- Setting the blend mode to SDL_BLENDMODE_BLEND results in the rectangle having incorrect alpha
- The problem is still present when using SDL_CreateRGBSurfaceWithFormat instead of TTF_RenderText_Blended
- The problem is not present when calling SDL_RenderDraw* or SDL_RenderFill* after SDL_RenderCopy and before SDL_DestroyTexture

Thanks
Comment 1 Sylvain 2019-08-15 18:56:59 UTC
An issue with the renderer sounds possible.
Even more, if you said you solved it by using another renderer.
But I have no window 7 to tell.

What sounds totally impossible is that changing the font color changes the bug.
  SDL_Color font_col={150, 150, 150, 255}; /*grey*/
whatever the color, it should be always there.

(because the SDL_Surface is just a  software memory that's created and is indendant from the renderer)

If not, maybe this is an issue with the screen ...


- update to latest SDL
- try disabling batching SDL_SetHint(SDL_HINT_RENDER_BATCHING, "0");

- debug the d3d renderer: 
https://hg.libsdl.org/SDL/file/9d23c9232bd8/src/render/direct3d/SDL_render_d3d.c
(check other renderers ...)
Comment 2 Ryan C. Gordon 2019-08-16 02:48:05 UTC
I’ll take a look at this.
Comment 3 b7874409 2019-08-16 12:13:26 UTC
Changing the font colour definitely does change the coulour of the rectangle even if this does seem very odd

With font_col={0, 0, 0, 255} the rectangle is black
With font_col={150, 150, 150, 255} the rectangle is a dark red
With font_col={255, 255, 255, 255} the rectangle is bright red the way it should be

In this example code only the first number (the R value) has an effect on the colour of the rectangle

I am aware that the SDL_Surface is just a software surface and is independent from the renderer,
perhaps it's the call to SDL_CreateTextureFromSurface that does something odd

I don't think there is a problem with the screen

I'm already using the latest stable version of SDL
Batching should already be disabled because I explicitly set the render driver to direct3d
Using SDL_SetHint(SDL_HINT_RENDER_BATCHING, "0") or SDL_SetHint(SDL_HINT_RENDER_BATCHING, "1") doesn't solve the problem

Thanks for your suggestions
Comment 4 b7874409 2019-08-20 18:30:17 UTC
Has anyone managed to reproduce this bug yet ?
Comment 5 Ryan C. Gordon 2019-09-04 04:31:47 UTC
I believe this is (possibly) corrected by the fixes made for Bug #4768. Can you grab the latest in revision control and try again?

--ryan.
Comment 6 b7874409 2019-09-04 12:27:38 UTC
This does appear to be corrected in the latest source snapshot SDL-2.0.10-13056.tar.gz (Updated Wed Sep 4) which should include https://hg.libsdl.org/SDL/rev/6ee12b88beed

Thanks
Comment 7 Sylvain 2019-09-05 08:51:24 UTC
Then, marked as fixed!
Comment 8 Ryan C. Gordon 2019-09-20 20:47:38 UTC
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.
Comment 9 Ryan C. Gordon 2019-09-20 20:48:44 UTC
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.