SDL_RenderDrawLine gives different results on different render backends #1626
Comments
…derer. One place known to differ in a significant way is a single line segment that starts and ends on the same point; the GL renderers will light up a single pixel here, whereas the software renderer will not. My current belief is this is a bug in the software renderer, based on the wording of the docs: "SDL_RenderDrawLine() draws the line to include both end points." You can see an example program that triggers that difference in Bug #2006. As it stands, the GL renderers might _also_ render diagonal lines differently, as the the Bresenham step might vary between implementations (one does three pixels and then two, the other does two and then three, etc). But this patch causes those lines to start and end on the correct pixel, and that's the best we can do, and all anyone really needs here. Not closing any bugs with this patch (yet!), but here are several that it appears to fix. If no other corner cases pop up, we'll call this done. Reference Bug #2006. Reference Bug #1626. Reference Bug #4001. ...and probably others...
|
OpenGL and GLES renderers should be improved here, in the latest in revision control. Any corner cases that remain (or are caused by this patch), PLEASE report them asap, as we would like this to be solid and never thought about again by the time 2.0.18 ships. Thanks! |
|
The GL renderer still draws lines one pixel shorter than the software one, missing the end point. Relevant specs: Ryzen 2400G built-in GPU, Linux, X11, Mesa 21.2.2, SDL latest git snapshot (commit |
|
It's definitely not doing it here... software: opengl: Are we really just going to have to draw a block of GL_POINTS to make this work everywhere? |
|
The modified test program I'm using, which dumps out the render to a .bmp for each render driver: #include <SDL.h>
int main(int argc, char* argv[])
{
int posX = 100, posY = 100, width = 320, height = 240;
SDL_Init(SDL_INIT_VIDEO);
int num = SDL_GetNumRenderDrivers();
for (int i = 0; i < num; i++) {
SDL_Window* win = SDL_CreateWindow("Hello World", posX, posY, width, height, 0);
SDL_Renderer* renderer = SDL_CreateRenderer(win, i, 0);
SDL_RendererInfo info;
SDL_GetRendererInfo(renderer, &info);
SDL_Log("renderer[%d] %s", i, info.name);
SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
SDL_RenderClear(renderer);
SDL_SetRenderDrawBlendMode(renderer, SDL_BLENDMODE_BLEND);
SDL_SetRenderDrawColor(renderer, 0, 255, 255, 128);
SDL_RenderDrawLine(renderer, 100, 100, 100, 100 + 100);
SDL_Surface *surface = SDL_CreateRGBSurfaceWithFormat(0, 800, 800, 32, SDL_PIXELFORMAT_RGB888);
SDL_RenderReadPixels(renderer, NULL, SDL_PIXELFORMAT_RGB888, surface->pixels, 800 * 4);
char fname[32];
SDL_snprintf(fname, sizeof (fname), "%s.bmp", info.name);
SDL_SaveBMP(surface, fname);
SDL_FreeSurface(surface);
SDL_RenderPresent(renderer);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(win);
}
//SDL_Delay(10000);
SDL_Quit();
return 0;
}You'll have an "opengl.bmp", "opengles2.bmp", "software.bmp" etc when it finishes running. |
|
On my desktop, the GL renderers draw the line one pixel shorter than the software one. On my laptop, which has an older AMD APU that uses the r600 Mesa driver instead of radeonsi, the line is always the same length, but there is a lot of random junk around it. I guess the test program should call So, does this mean the bug is actually in the radeonsi Mesa driver? |
Yeah, that's a bug in the test program. I'm going to edit the comment to add it to the source code.
Possibly. Might just be a rounding error working out in one place and not another. I'll check my math again. |
|
Okay, closing this with several other bugs. |
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: HG 2.0
Reported for operating system, platform: All, All
Comments on the original bug report:
On 2014-09-01 16:23:27 +0000, Nicolae Berendea wrote:
On 2014-09-13 14:03:15 +0000, Nader Golbaz wrote:
On 2014-09-15 07:27:36 +0000, Nicolae Berendea wrote:
On 2018-07-07 09:53:11 +0000, Björn Sundin wrote:
On 2020-01-23 21:00:45 +0000, Nicolae Berendea wrote:
On 2020-02-10 18:06:37 +0000, Ryan C. Gordon wrote:
On 2020-02-11 17:11:29 +0000, Nicolae Berendea wrote:
On 2020-02-11 17:24:03 +0000, Nicolae Berendea wrote:
On 2020-02-11 17:48:50 +0000, Nicolae Berendea wrote:
On 2020-02-12 07:32:15 +0000, Sam Lantinga wrote:
On 2020-02-12 20:14:56 +0000, Ryan C. Gordon wrote:
On 2020-02-12 20:15:28 +0000, Ryan C. Gordon wrote:
On 2020-02-17 21:17:29 +0000, Ryan C. Gordon wrote:
On 2020-10-26 03:18:55 +0000, Anthony @ POW Games wrote:
On 2020-10-27 00:28:08 +0000, Anthony @ POW Games wrote:
On 2020-11-14 02:55:40 +0000, Anthony @ POW Games wrote:
On 2020-11-18 16:06:05 +0000, Ryan C. Gordon wrote:
The text was updated successfully, but these errors were encountered: