It appears that when running on Windows with the OpenGL backend (not Direct3D) SDL_RenderDrawLine() is not plotting the final endpoint. So for example:

SDL_RenderDrawLine(renderer, 200, 300, 300, 300);

is not plotting the pixel at 300,300 at all. This worked correctly in SDL 2.0.16.

The program below will demonstrate this; it should draw a green square without any black line, but with SDL 2.0.18 and Windows 10 it plots this: Commenting out the OpenGL hint results in correct behavior.

/**************************************************************\
* Testcase to demonstrate a possible regression in SDL 2.0.18  *
* when running with the OpenGL rendering backend on Windows 10 *
\**************************************************************/

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "SDL2/SDL.h"

#define SCREEN_WIDTH  640
#define SCREEN_HEIGHT 500

int main(int argc, char* argv[])
{
int y, running = 1;
SDL_Event ev;
SDL_Window *window;
SDL_Renderer *renderer;

if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER | SDL_INIT_EVENTS) != 0)
{
	SDL_ShowSimpleMessageBox(SDL_MESSAGEBOX_ERROR,
		"Testcase", SDL_GetError(), NULL);
	return 1;
}

	SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengl");

window = SDL_CreateWindow("Testcase",  SDL_WINDOWPOS_CENTERED,  SDL_WINDOWPOS_CENTERED, 
		SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_OPENGL | SDL_WINDOW_RESIZABLE);
if (window == NULL)
{
	SDL_ShowSimpleMessageBox(SDL_MESSAGEBOX_ERROR,
		"Testcase", SDL_GetError(), NULL);
	SDL_Quit();
	return 5;
}

renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED |SDL_RENDERER_PRESENTVSYNC);
if (renderer == NULL)
{
	SDL_DestroyWindow(window);
	SDL_ShowSimpleMessageBox(SDL_MESSAGEBOX_ERROR,
		"Testcase", SDL_GetError(), NULL);
	SDL_Quit();
	return 6;
}

while (running)
{
	while (SDL_PollEvent(&ev))
		switch (ev.type)
		{
			case SDL_QUIT:
				running = 0;
		}

// Clear the window to white:
	SDL_SetRenderDrawColor(renderer, 255, 255, 255, 255);
	SDL_RenderClear(renderer);

// Draw a black vertical line from 300,200 to 300,300:

	SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
	SDL_RenderDrawLine(renderer, 300, 200, 300, 300);

// Draw a series of green horizontal lines from x = 200 to x = 300,
// these should overwrite the previously-drawn black line:

	SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
	for (y = 200; y <= 300 ; y++)
		SDL_RenderDrawLine(renderer, 200, y, 300, y);

	SDL_RenderPresent(renderer);
}

SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();

exit(0);
}

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know Reported for operating system, platform: All, All

Comments on the original bug report:

On 2020-01-22 15:55:25 +0000, David Demelier wrote:

Hi,

I already sent some ideas by email but I've been convinced by an individual on the IRC channel to do this on the bugzilla to get reviews.

Here's a list of things I'd love to see and implement (as a developer myself) for SDL 3.

Any feedback is welcomed.

Stricter coding, naming style.

For the moment there are high number of style issues in the API. Some symbols are SDL_lowerCased and some are SDL_UpperCased. Some are not even prefixed by SDL_.

Every functions that are tighed to a specific structure should:

• Be prefixed by its name: SDL_Foo (object), SDL_FooOpen, SDL_FooDestroy, SDL_FooUpdate, etc.
• Take the object as first argument: SDL_FooUpdate(SDL_Foo *, ...);

Getter and setters should be named as following:

• SDL_Namespace(Get|Set)What (e.g. SDL_Renderer(Get|Set)DrawColor)

Constructors and destructors should be named as following if applicable:

• SDL_NamespaceOpen (e.g. SDL_JoystickOpen)
• SDL_NamespaceDestroy (e.g. SDL_JoystickDestroy)

If objects are not meant to be dynamically allocated, the names "Init" and "Finish" or "Close" can also be used.

Proper semantic versioning.

One SDL 2.0.x version added sensor support, while it should be bugfix instead. The current versioning scheme makes too difficult to check what features were provided and when at a glance.

What did 2.0.1 provided? What 2.0.2 provided?

In the head of packagers, they feel like they are bugfixes while they've added new APIs!

The Semantic Versioning is the most appropriate versioning scheme for libraries.

• Major : massive breakage allowed in the API (not every year though, somewhat like every 5-6 years).
• Minor : improvements and new features added with API compatibility honored
• Patch : simple bugfixes

Simplify development process

At the moment there is no much information about the way to contribute to SDL. One can ping maintainer using patches via mail but are sometimes missed. Also they are linked to an individual and can not be reviewed by others.

Since SDL does not have a system for reviewing yet, I propose that a development mailing-list is re-opened and people could send their patch via hg email as the bugzilla is more tailored for bug reporting.

Removing useless platforms.

• arts: no longer used
• winrt: too, AFAIK

Fixing inconsistencies where some functions use plain primitives types rather than structs.

If we have structs, then functions should always operate on them. Since C99, compound literals makes life easier while passing temporaries to functions.

• SDL_SetRenderDrawColor takes 4 ints

• SDL_SetPaletteColor take a SDL_Color object

• SDL_RenderDrawLine takes 4 ints

• SDL_RenderSetClipRect takes a SDL_Rect

The color handling is sometimes in 4 ints, sometimes SDL_Color.

Getting rid of dozens of buildsystems to unique one: CMake.

There are just too many build systems in the tree and that is too complicated for users, developers and packagers. Also, having only one for a portable library that SDL is, makes difficult to merge all checks/operations in all build systems.

Also, lots of people do not rely on the SDL CMake configuration package files provided as autoconf does not install them. Having CMake only will simplify the integration and maintainance.

Use doxygen documentation to avoid outdated information on the wiki.

I've literally spent 3 hours to document the sensor API on the wiki. That's a big waste of time. SDL headers are already almost documented in doxygen, it should be completed with missing bits and the only source of truth.

Changing something in one enum results in editing the wiki as well.

Rename pkg-config files

The SDL pkg-config file is sdl2 while addons are SDL2_*.

Making addons first class citizen and built from the same source tree with proper naming.

The SDL addons feel they are separate projects as they still do not have any public visibility from the libsdl.org website. At a glance, a newcomer don't even know these libraries exist.

They have the same troubles as the above paragraphs (cmake, consistency, etc.).

I propose the simple inclusion of these addons with a new naming scheme for them and a simpler API. Also, they will be available as separate shared/static libraries controlled at build time. Thus, people who don't need SDL_mixer or SDL_ttf can simply not build/link theme.

SDL_ttf new API

Every functions start with SDL_Font.

• SDL_Font (struct)
• SDL_FontStyle (enum SDL_FONT_SOLID, SDL_FONT_SHADED, SDL_FONT_BLENDED)
• TTF_Init -> SDL_FontInit()
• TTF_OpenFont* -> SDL_FontOpen*
• TTF_(Get|Set)Font* -> SDL_Font(Get|Set)*
• TTF_FontHeight -> SDL_FontGetHeight
• TTF_FontAscent -> SDL_FontGetAscent
• TTF_FontDescent -> SDL_FontGetDescent
• TTF_FontLineSkip -> SDL_FontGetLineSkip
• TTF_FontFaces -> SDL_FontGetFaces
• TTF_GlyphIsProvided -> SDL_FontIsGlyphProvided
• TTF_GlyphMetrics -> SDL_FontGetGlyphMetrics
• TTF_SizeText -> Should be removed, UTF-8 is the standard
• TTF_SizeUTF8 -> SDL_FontTextMetrics
• TTF_SizeUNICODE -> Should be removed, UTF-16 is deprecated
• TTF_Render* -> SDL_FontRender(const char *, SDL_FontStyle) (UTF-8 only)

SDL_image new API

Every function start with SDL_Image.

• SDL_ImageFormat (enum SDL_IMAGE_(CUR|ICO|BMP|PNM|...))
• IMG_Init -> SDL_ImageInit()
• IMG_Load -> SDL_ImageOpen(const char *path)
• IMG_Load_RW -> SDL_ImageOpen_RW
• IMG_LoadTyped_RW -> SDL_ImageOpenTyped_RW(SDL_RWOps *, SDL_ImageFormat)
• IMG_is* -> SDL_ImageGetType (returns SDL_ImageFormat)

SDL_mixer new API

Basic functions start with SDL_Mixer.

• Mix_Init -> SDL_MixerInit
• Mix_OpenAudio -> SDL_MixerOpen
• Mix_CloseAudio -> SDL_MixerClose
• Mix_GetNumChunkDecoders -> SDL_MixerGetNumChunkDecoders
• Mix_GetChunkDecoder -> SDL_MixerGetChunkDecoder

Channel and groups functions

• Mix_AllocateChannels -> SDL_ChannelsAllocate
• Mix_ReserveChannels -> SDL_ChannelsReserve
• Mix_Group* -> SDL_ChannelGroup*
• Mix_HaltGroup -> SDL_ChannelGroupHalt
• Mix_Volume -> SDL_ChannelVolume
• Mix_PlayChannel -> SDL_ChannelPlay
• Mix_PlayChannelTimed -> SDL_ChannelPlayTimed
• Mix_FadeInChannel -> SDL_ChannelFadeIn
• Mix_FadeInChannelTimed -> SDL_ChannelFadeInTimed
• Mix_Pause -> SDL_ChannelPause
• Mix_Resume -> SDL_ChannelResume
• Mix_HaltChannel -> SDL_ChannelHalt
• Mix_ExpireChannel -> SDL_ChannelExpire
• Mix_FadeOutChannel -> SDL_ChannelFadeOut
• Mix_ChannelFinished -> SDL_ChannelHasFinished
• Mix_Playing -> SDL_ChannelIsPlaying
• Mix_Paused -> SDL_ChannelIsPaused
• Mix_FadingChannel -> SDL_ChannelGetFading
• Mix_GetChunk -> SDL_ChannelGetChunk

Chunk functions

• Mix_LoadWAV -> SDL_ChunkOpen
• Mix_LoadWAV_RW -> SDL_ChunkOpen_RW
• Mix_QuickLoad -> SDL_ChunkQuickOpen
• Mix_QuickLoad_RW -> SDL_ChunkQuickOpen_RW
• Mix_FreeChunk -> SDL_ChunkDestroy
• Mix_VolumeChunk -> SDL_ChunkGetVolume

Music functions

• Mix_GetNumMusicDecoders -> SDL_MusicGetNumDecoders
• Mix_GetMusicDecoder -> SDL_MusicGetDecoder
• Mix_LoadMUS -> SDL_MusicOpen
• Mix_FreeMusic -> SDL_MusicDestroy
• Mix_PlayMusic -> SDL_MusicPlay
• Mix_FadeInMusic -> SDL_MusicFadeIn
• Mix_FadeInMusicPos -> SDL_MusicFadeInPos
• Mix_HookMusic -> SDL_MusicHook
• Mix_VolumeMusic -> SDL_MusicVolume
• Mix_PauseMusic -> SDL_MusicPause
• Mix_ResumeMusic -> SDL_MusicResume
• Mix_RewindMusic -> SDL_MusicRewind
• Mix_SetMusicPosition -> SDL_MusicSetPosition
• Mix_SetMusicCMD -> SDL_MusicSetCommand
• Mix_HaltMusic -> SDL_MusicHalt
• Mix_FadeOutMusic -> SDL_MusicFadeOut
• Mix_HookMusicFinished -> SDL_MusicSetHookFinished
• Mix_GetMusicType -> SDL_MusicGetType
• Mix_PlayingMusic -> SDL_MusicIsPlaying
• Mix_PausedMusic -> SDL_MusicIsPaused
• Mix_FadingMusic -> SDL_MusicIsFading
• Mix_GetMusicHookData -> SDL_MusicGetHookFinished

Effect functions

• Mix_RegisterEffect -> SDL_EffectRegister
• Mix_UnregisterEffect -> SDL_EffectUnregister
• Mix_UnregisterAllEffects -> SDL_EffectUnregisterAll
• Mix_SetPostMix -> SDL_EffectSetPostMix
• Mix_SetPanning -> SDL_EffectSetPanning
• Mix_SetDistance -> SDL_EffectSetDistance
• Mix_SetPosition -> SDL_EffectSetPosition
• Mix_SetReverseStereo -> SDL_EffectSetReverseStereo

SDL_net

To my humble opinion, this library should be removed as they are many networking library in C including POSIX.

On 2020-01-23 02:56:03 +0000, Sam Lantinga wrote:

I agree with most of this feedback, and like the satellite library naming suggestions, thanks!

Some comments on the build system:

Not all platforms have CMake, and many developers don't have CMake installed. Windows developers should be able to use Visual Studio, Mac developers should be able to use Xcode. I should be able to use autoconf. :)

I'm fine with CMake being the recommended build environment, and even stripping out support for non-UNIX platforms from it, but I've run into enough problems with it over the years that I don't use CMake. Also, note that the official SDL windows binaries are built on Mac using mingw64, to integrate with build scripts and avoid C runtime dependencies, and that currently requires autotools.

On 2020-03-23 22:53:39 +0000, wrote:

Simplify development process

I think there should be more discussion on just moving the center of development to github / git. I'm aware that this has been proposed by many people over the years, but I feel it hasn't gotten the proper attention it needs.

Github or at least git, would make it much easier for people to contribute to the development of SDL.

On 2020-03-24 01:04:30 +0000, Ryan C. Gordon wrote:

(In reply to daegon.dhsk from comment # 2)

Github or at least git, would make it much easier for people to contribute to the development of SDL.

This is a hard no from me, both to GitHub and git itself.

--ryan.

On 2020-03-24 01:15:27 +0000, wrote:

(In reply to Ryan C. Gordon from comment # 3)

(In reply to daegon.dhsk from comment # 2)

Github or at least git, would make it much easier for people to contribute to the development of SDL.

This is a hard no from me, both to GitHub and git itself.

--ryan.

Could we get some details on the background?

On 2020-03-24 03:32:52 +0000, Ryan C. Gordon wrote:

(In reply to daegon.dhsk from comment # 4)

Could we get some details on the background?

Even if I didn't personally think git is a lousy system, Mercurial is working fine for us and changing it just introduces unnecessary friction.

As for GitHub: we have been burned by cloud providers several times over the past 20 years, and have spent significant effort engineering our infrastructure so we own all of it. Becoming reliant on an unnecessary for-profit company for the most crucial piece of our workflow is not something we're willing to do.

--ryan.

On 2020-03-24 08:15:06 +0000, David Demelier wrote:

(In reply to daegon.dhsk from comment # 2)

Simplify development process

I think there should be more discussion on just moving the center of development to github / git. I'm aware that this has been proposed by many people over the years, but I feel it hasn't gotten the proper attention it needs.

Github or at least git, would make it much easier for people to contribute to the development of SDL.

I can't understand this hype to request people to move to Git. Git is by far much more complicated than Mercurial so I'd like to know what's “easier” for you to contribute.

If by easier you mean that you can send a pull request, please not that sending a patch is by far much easier:

hg clone http://hg.libsdl.org/SDL && cd SDL
vim
hg ci
hg export OR hg email

That's it.

You can't come to a project and ask them to change their tooling, this is a subjective material. I don't like Git but I don't ask projects to move from Git to Mercurial. I don't like meson and I don't request projects that use meson to switch to CMake. I can go for a while.

The only way we could improve the contributing process for SDL is to provide a detailed documentation because for now there are not that much. So some people send emails and some tasks on bugzilla. We need a unified, detailed process. That's it.

On 2020-04-02 22:25:09 +0000, David Ludwig wrote:

(In reply to David Demelier from comment # 6)

If by easier you mean that you can send a pull request, please not that sending a patch is by far much easier:

hg clone http://hg.libsdl.org/SDL && cd SDL
vim
hg ci
hg export OR hg email

That's it.

Wait, vim is now part of the easy route?! (and I like vim, for some things at least) ;-)

In all seriousness, a move to git sounds ok to me, though not one to GitHub and its partially-closed nature. I find git's overall ecosystem to be MUCH nicer than Mercurial's (enough that I am willing to argue that Mercurial isn't always the "easiest" option, not any more at least), and would probably welcome a move to git repos. I have, within the past few years, lost Mercurial support in some valuable-to-me tools (BitBucket, especially), and finding good, alternative tooling hasn't always been easy.

As for the initial suggestions, I'm in favor of a lot of it! I especially like the idea of iterating on SDL's function names. Having a scheme along the lines of SDL_ seems very helpful with regards to editor auto-completion.

I'd like to add one suggestion with regards to naming: include the major version number in the prefix. I.e. SDL3.h, SDL3_RenderSetDrawColor, etc. It would make SDL 3.x detection be a matter of finding a header, rather than finding a header and parsing it, which might not always be possible (with C++'s __has_include, for example). It would also help make it possible to distinguish SDL 1.x and 2.x code from 3.x code, which I could see helping if and when porting stuff to 3.x.

Regarding dropping WinRT, it's my understanding that Xbox One still requires using those APIs. Unless that changes, I think removing that support would be bad (though, that platform's SDL code could definitely use some improvement, with at least some pruning of older, WinRT SDK support).

Regarding build-systems, I like the idea of better CMake integration, but I would like to see file-globbing of SDL's src directory be an option, too, at least for platforms where this is possible. (One of these days, I should finish my support for this. I've had prototypes working on Apple-platforms, as well as Windows, at one point or another).

As for including satellite libraries in SDL-proper, this makes me leery as it seems like it would introduce a lot of additional dependencies in SDL, which is already inherently complex due to the number of platforms it supports. Having naming changes within them does sound nice, and perhaps possible without needing to include them in SDL itself.

On 2020-05-26 07:50:59 +0000, Jan Niklas Hasse wrote:

Windows developers should be able to use Visual Studio, Mac developers should be able to use Xcode.

Both can be generated using CMake :)

On 2020-11-28 11:36:22 +0000, Dominik Reichardt wrote:

Windows developers should be able to use Visual Studio, Mac developers should be able to use Xcode.

Both can be generated using CMake :)

I have only tried a few times but those projects all didn't generate a working xcode project. No idea if this is a problem with their CMake files but if you have to work extensively on the Xcode project file each time you generate it from code, then it is no good, IMO worse than a partially working included one.

So, when I see there is only CMake, I try to find whether someone else already built an Xcode project file or just turn away and don't bother.

Generation of the unix stuff generally works though.

On 2020-11-28 11:39:12 +0000, Jan Niklas Hasse wrote:

I have only tried a few times but those projects all didn't generate a working xcode project.

What do you mean by "those projects"?

On 2020-11-28 11:44:23 +0000, Dominik Reichardt wrote:

I have only tried a few times but those projects all didn't generate a working xcode project.

What do you mean by "those projects"?

the projects that had only Cmake and I tried to generate the Xcode project with

On 2020-11-28 11:59:54 +0000, Jan Niklas Hasse wrote:

Ah I see. I think some projects don't take Xcode into account and use some unidiomatic CMake constructs that break it.

It is definitely possible though and works great in my projects. It's a good idea to add a CI job which generates and builds with -GXcode.

The attached set of patches implement client-side window decorations on Wayland using 'libdecoration' from https://gitlab.gnome.org/jadahl/libdecoration. The libdecoration dependency is downloaded directly from upstream at build-time.

This fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2710

This fixes #3739.

Cheers and thanks for making Linux gaming happen :-)

This is a ~~draft~~ patch that will (at last) prioritize the Wayland video driver over X11. This is here purely for internal testing only and is NOT meant for wider community testing; to test SDL Wayland support you should set SDL_VIDEODRIVER=wayland instead.

Click here for the SDL Wayland bug tracker.

The Big List of Annoying Things That Aren't SDL's Fault:

• Event queue overflow issues (server-side, also affects Xwayland)
• Steam overlay support

The Big List of EGL Stuff That Might Be a Problem:

• SwapBuffers timeout support

This Big List of Things in X11 That Wayland Might Also Want but It's Not a Huge Deal:

• XCURSOR_THEME/SIZE protocol (we still use the environment variables)
• GetDisplayUsableBounds - xdg-shell v4?
• SetWindowIcon - xdg-decoration/libdecor?
• GetWindowBordersSize - xdg-decoration/libdecor?

Known Issues:

• GNOME 40.3 doesn't toggle fullscreen correctly with CSD

Fixes #2710. Fixes #4988.

Right now we track external dependencies as code checked into the SDL_* libraries with .patch files with SDL specific changes to those packages. Those are cumbersome to maintain (some of the .patch files are out of date) and time consuming to update when upstream changes occur or we want to pull in CVE fixes and other improvements.

I propose that we fork the upstream projects into libsdl-org (or create repositories for those projects not already in git) and use git submodules to include those dependencies into SDL libraries. This would largely affect SDL_image and SDL_mixer, but could be used anywhere we depend on third party libraries.

The documentation for git submodules is here: https://git-scm.com/book/en/v2/Git-Tools-Submodules

It looks like the work flow is greatly complicated by using git submodules, and it's easy to forget the various steps needed to use them properly if the submodule options aren't already in the git config.

@smcv, do you have thoughts on the pros and cons of this approach?

@icculus, @1bsyl, @sezero, what are your thoughts?

Hello!

Recently I found that some users has problem that touchscreen doesn't work for them. Later, by my log file, I found that SDL_GetNumTouchDevices() got returned two touch screen devices, and seems, one of them is a ghost tha steals control and makes no way to use the real one. At my phone the touch control works fine, however, I suddely found it returns !!!6!!! touch devices :scream:

(Note, to choose the device to work, I do scan all devices to find any that has fingers placed)

• My phone is SGN9 with Android 10
• My buddy's phone is another Samsung phone with Android 11
• Other folk used Xiaomi with Android 11 and had the similar problem of touch screen not working.
• I use SDL 2.0.18, but plan to update into 2.0.20.
• All returned touch devices described as direct input

Was this bug been fixed at 2.0.20? Why these mystery touch devices got appear here?

Configure events from compositors have an extremely annoying habit of giving us completely bogus sizes, from all sorts of places. Thankfully, the protocol gives us the ability to completely ignore the width/height and just stick with what we know, so for all windows that are not meant to be resized, pretend we never even got the width/height at all, the compositor is required to respect our dimensions whether they match configure's suggestion or not.

Tested with FEZ, Capsized, Streets of Rage 4, a handful of Unity games, Baba Is You, Portal 2, and Super Hexagon.

This fixes an issue with xdg-shell where going from fullscreen->windowed would give us configure event that very clearly ignored dimensions passed via a SetWindowSize call. Should fix #4572 to the extent that is possible (need a libdecor and GNOME 40 update first). #4571 is still an issue.

CC @cgutman, @christianrauch, @dos1. This manages to remove the dispatch, but a notable detail is that ~~this also made floating_width/height obsolete as far as I could tell~~ nope, was still needed, this is fixed. Testing both fullscreen toggling and maximize/restore seemed to work just fine on GNOME 40 and Plasma 5.22.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.14 Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2021-02-02 22:01:29 +0000, Vitaly Novichkov wrote:

Hello!

I found that the bug against the black screen on resuming got back, it happens on various devices:

• Open the game
• Switch to another application, try to do anything
• Try to switch the game back
• You'll get the black screen
• However, the game itself will resume its normal work, but a black screen
• No matter what to draw: textures or color-filled shapes
• I do render into texture, then into the screen. Also, I draw some shapes on the screen directly. This happens on Android 4.1, 5.1, Android 10, also on Android 8 the bug confirmed.

At the logger I get the next spamming:

02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/libEGL: eglMakeCurrent:777 error 3002 (EGL_BAD_ACCESS) 02-03 00:55:02.482 3666-3690/ru.wohlsoft.thextech.debug E/EGL_emulation: tid 3690: eglMakeCurrent(1500): error 0x3002 (EGL_BAD_ACCESS)

---

If needed, I can try to compose a simple unit test that reproduces this bug

On 2021-02-03 07:21:14 +0000, Sylvain wrote:

Did you make sure not to call any rendering function between the two events SDL_WILL_ENTER_BACKGROUND and SDL_DID_ENTER_FOREGROUND

see docs/README-android.md

On 2021-02-03 21:50:38 +0000, Vitaly Novichkov wrote:

Oh, interesting, how I messed this up? Gonna try this out... Thanks for the notice!

On 2021-02-03 22:19:12 +0000, Vitaly Novichkov wrote:

btw, does that also counting the rendering into the texture too? Okay, I'll check.

On 2021-02-03 23:16:12 +0000, Vitaly Novichkov wrote:

Nope, that didn't help completely, even I made the strict avoiding of any render functions being called, I still can get the black screen and the EGL_BAD_ACCESS error after I switched application back

On 2021-02-04 07:24:08 +0000, Sylvain wrote:

that really really is a reason, are you depleting the event loop ? no multi-threading ?

really stop using renderer after reading WILL_ENTER_BG, and start again using DID_ENTER_FG.

are you using the SDL_Renderer or your own context ?

On 2021-02-04 08:02:26 +0000, Vitaly Novichkov wrote:

are you depleting the event loop ?

No, I do call the event loop sequentially

no multi-threading ?

No, single threading

really stop using renderer after reading WILL_ENTER_BG, and start again using DID_ENTER_FG.

Oh, I did a mistake - I used the WILL_ENTER_FG instead of WILL_ENTER_BG event, I should re-try this experiment again.

are you using the SDL_Renderer or your own context ?

I use SDL_Renderer

On 2021-02-04 08:32:58 +0000, Vitaly Novichkov wrote:

Okay, I really made sure no render will be called between those events, I even added asserts to crash if any of the render calls will be executed after SDL_APP_WILLENTERBACKGROUND event, and allow them to be called after SDL_APP_DIDENTERFOREGROUND event that unlocks the render.

On 2021-02-04 08:35:03 +0000, Vitaly Novichkov wrote:

The result is the same, on Android 10:

• open the game
• switch another application (my log will print the fact "SDL_APP_WILLENTERBACKGROUND" was coming, I made sure those messages be printed to see the result)
• All big render calls got blocked by a boolean
• All small routine render calls got blocked by assert
• Switch the game back (my log will print the fact of "SDL_APP_DIDENTERFOREGROUND")
• Black screen

On 2021-02-04 08:41:00 +0000, Vitaly Novichkov wrote:

I also checked the fact of any attempts to call the render calls, just by spamming of the same message into the log, the spamming is off completely when entering background, and getting on back when entered background.

On 2021-02-04 08:48:27 +0000, Sylvain wrote:

are you depleting the event loop ? No, I do call the event loop sequentially

before each frame, and also periodically, you must poll all the events.

Just to make sure, all functions using the SDL_renderer includes: RenderCopy, RenderPresent, CreateTexture, UpdateTexture, ..

On 2021-02-04 08:55:37 +0000, Vitaly Novichkov wrote:

before each frame, and also periodically, you must poll all the events.

Yes, that what I already do, I poll all events in every loop cycle

Just to make sure, all functions using the SDL_renderer includes:

CreateTexture, UpdateTexture I don't call them during the loop except for the lazy-decompression algorithm that gets executed when calling the big render call, I blocked by the boolean

RenderCopy, RenderPresent Both blocked by the boolean I do set

On 2021-02-04 09:15:34 +0000, Sylvain wrote:

This look strange ...

you have recent SDL2 lib + sync'ed java file ?

you can add trace here: http://hg.libsdl.org/SDL/file/1cde3dd0f44d/src/video/android/SDL_androidevents.c to backup and restore context

maybe log the event: SDL_RENDER_DEVICE_RESET

with those print do you have a full adb log to check ?

try with a simpler test case ?

On 2021-02-04 09:47:04 +0000, Vitaly Novichkov wrote:

Closing to the evening (UTC+3) I'll try to compose a simple test program that simulates my and verify the work.

On 2021-02-04 09:52:02 +0000, Vitaly Novichkov wrote:

Anyway, without of SDL2 patching, I did the tracking of SDL_RENDER_DEVICE_RESET event, and I got next:

02-04 12:50:08.444 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Entering background
02-04 12:50:16.879 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Resumed foreground
02-04 12:50:19.591 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Entering background
02-04 12:50:23.807 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Resumed foreground
02-04 12:50:27.021 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Entering background
02-04 12:50:32.787 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Resumed foreground
02-04 12:50:32.787 2791-2814/ru.wohlsoft.thextech.debug D/TRACKERS: Android: Render Device Reset

I had multiple times to go into the background, and then, resume back, but the thing got blacked once SDL_RENDER_DEVICE_RESET was happened at my log

On 2021-02-04 09:54:51 +0000, Vitaly Novichkov wrote:

So, seems once this event came:

---

SDL_RENDER_TARGETS_RESET

the render targets have been reset and their contents need to be updated (>= SDL 2.0.2)

SDL_RENDER_DEVICE_RESET

the device has been reset and all textures need to be recreated (>= SDL 2.0.4)

I should reload all the textures again, right?

On 2021-02-04 09:55:33 +0000, Vitaly Novichkov wrote:

I'll try some in the evening after my workday will finish.

On 2021-02-04 12:26:04 +0000, Sylvain wrote:

yep, re-create texture once you get the device reset. (you don't need to recreate the SDL renderer)

On 2021-02-04 12:53:31 +0000, Sylvain wrote:

Updated the android README file because this is a recurrent issue http://hg.libsdl.org/SDL/rev/8609e27b3eed

feel free to improve it!

I am rendering raw frames from a camera using SDL with hardware acceleration, frames are NV12 pixel format. The NV12 frames are rendered with opengles2 for fast rendering and low CPU usage. The platform is Rockchip RK3568 for reference. SDL2 with opengles2/3 and hw acceleration works fine. Streaming the camera using raw NV12 gives ~30% CPU usage out of 400%, and using ffplay with SDL2 (opengles2 with hw acceleration) gives ~60% CPU usage out of 400% due to possibly converting NV12 and resizing via software prior to rendering with SDL2 (opengles2 and hw acceleration). This is the reason i want to use SDL_PIXELFORMAT_NV12.

SDL info

width: 1920 x height: 1080
INFO: libSDL: compiled with=2.0.19 linked against=2.0.19
INFO: Renderer Driver (default): (null)
INFO: Renderer Driver (set): opengles2
SDL information:
    SDL_FRAMEBUFFER_ACCELERATION: (null)
    SDL_RENDER_DRIVER: opengles2
    SDL_RENDER_OPENGL_SHADERS: (null)
    SDL_RENDER_LOGICAL_SIZE_MODE: (null)
    SDL_RENDER_SCALE_QUALITY: (null)
    SDL_RENDER_VSYNC: (null)
    SDL_VIDEO_HIGHDPI_DISABLED: (null)
    SDL_VIDEO_WIN_D3DCOMPILER: (null)
    SDL_VIDEO_WINDOW_SHARE_PIXEL_FORMAT: (null)
    SDL_VIDEO_DOUBLE_BUFFER: (null)

the issue

The Image rendered looks wrong with SDL_PIXELFORMAT_NV12, maybe some padding missed with SDL_PIXELFORMAT_NV12

Here is the image rendered (raw frame) with SDL_PIXELFORMAT_NV12:

Here is the raw frame from the camera (for analysis) and a png created with ffmpeg from the raw nv12 frame: 1920x1080.nv12.tar.gz

Checking the image with ffmpeg: ffmpeg -y -f rawvideo -s 1920x1080 -pix_fmt nv12 -i 1920x1080.nv12 -pix_fmt rgb24 1920x1080.nv12.png

Streaming with ffplay:

excerpt code

The code used to render the frame:

sdlRenderer = SDL_CreateRenderer(sdlWindow, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_TARGETTEXTURE | SDL_RENDERER_PRESENTVSYNC)
sdlTexture = SDL_CreateTexture(sdlRenderer, SDL_PIXELFORMAT_NV12, SDL_TEXTUREACCESS_STREAMING, videoIn->width, videoIn->height + 32);

SDL_LockTexture(sdlTexture, NULL, (void**)&p, &pitch);
if (videoIn->formatIn == V4L2_PIX_FMT_NV12) {
    memcpy(p, videoIn->framebuffer, videoIn->bsize /*videoIn->width * (videoIn->height) * 3 / 2*/);
} else {
    memcpy(p, videoIn->framebuffer, videoIn->width * (videoIn->height) * 2);
}
SDL_UnlockTexture(sdlTexture);
SDL_RenderClear(sdlRenderer);
SDL_RenderCopy(sdlRenderer, sdlTexture, NULL, NULL);
SDL_RenderPresent(sdlRenderer);

Second attempt to render triangles with SDL, adding SDL_RenderGeometry

In this version, triangles can be non uniform, with a per vertex color. Textures can also have a per vertex modulation.

Using the adviced prototype:

typedef struct SDL_Vertex{
    SDL_FPoint position;        /**< Vertex position, in SDL_Renderer coordinates  */
    SDL_Color  color;           /**< Vertex color */
    SDL_FPoint tex_coord;       /**< Normalized texture coordinates, if needed */
} SDL_Vertex;

/**
 *  \brief Render a list of triangles, optionally using a texture and indices into the vertex array
 *  Color and alpha modulation is done per vertex (SDL_SetTextureColorMod and SDL_SetTextureAlphaMod are ignored).
 *
 *  \param texture      (optional) The SDL texture to use.
 *  \param vertices     Vertices.
 *  \param num_vertices Number of vertices.
 *  \param indices      (optional) An array of integer indices into the 'vertices' array, if NULL all vertices will be rendered in sequential order.
 *  \param num_indices  Number of indices.
 *
 *  \return 0 on success, or -1 if the operation is not supported
 */
extern DECLSPEC int SDLCALL SDL_RenderGeometry(SDL_Renderer *renderer,
                                               SDL_Texture *texture,
                                               SDL_Vertex *vertices, int num_vertices,
                                               int *indices, int num_indices);

Description

Back-end added: Software, Opengl, OpenGLES2, D3D11, METAL, D3D9, OpengGLES Metal and OpenGLES2 are modified more internally so that 'color' isn't uniform anymore but an attribute. Software Renderer tries also to reconstruct SDL_Rect from Vertex, and to use faster SDL_RenderCopy when possible.

I've checked that it integrates correctly with DearImGui. (see example files here: https://github.com/ocornut/imgui/pull/3926 ) And also with Spine (using spine-c runtime) With Nuklear ( https://github.com/Immediate-Mode-UI/Nuklear/pull/280 ) With Librocket (https://github.com/libRocket/libRocket/pull/301 ) With Microui ( https://github.com/rxi/microui/pull/48 )

Some parts are used from the various patches

Existing Issue(s)

Referencing #772 : SDL_RenderGeometry #692 : Implement polygon rendering

I want to create egl context using my sdl android app. I know I can create the built in SDL_GL_createcontext but it doesn't work in my case. It only shows black screen on my attempt to embed mpv on android using SDL. That's why I thought of using EGL. Down below is my code. However the sdl asserts the following. Am I missing something here? The code below works fine in SDL windows application using angle jwith just simple difference. I am using the stable version of SDL.

#include <stdlib.h>
#include <stdio.h>

#include "SDL.h"
#include "SDL_syswm.h"

#include <EGL/egl.h>
#include <GLES2/gl2.h>

using namespace std;


int main(int argc, char* argv[])
{
    SDL_Window* window = 0;
    
    if (0 != SDL_Init(SDL_INIT_VIDEO))
    {
        fprintf(stderr, "\nUnable to initialize SDL: %s\n", SDL_GetError());
        return 1;
    }
    window = SDL_CreateWindow("Glad Sample",
        SDL_WINDOWPOS_CENTERED,
        SDL_WINDOWPOS_CENTERED,
        800, 600, SDL_WINDOW_SHOWN |
        SDL_WINDOW_OPENGL);

  EGLint configAttribList[] =
    {
        EGL_RED_SIZE,       8,
        EGL_GREEN_SIZE,     8,
        EGL_BLUE_SIZE,      8,
        EGL_ALPHA_SIZE,     8 /*: EGL_DONT_CARE*/,
        EGL_DEPTH_SIZE,     EGL_DONT_CARE,
        EGL_STENCIL_SIZE,   EGL_DONT_CARE,
        EGL_SAMPLE_BUFFERS, 0,
        EGL_NONE
    };

    EGLint surfaceAttribList[] =
    {
        // EGL_CONTEXT_CLIENT_VERSION, 2,
         EGL_WIDTH, 800,
         EGL_HEIGHT, 600,
         EGL_NONE

    };
    EGLint attribListPbuffer[] = {
    EGL_SURFACE_TYPE, EGL_PBUFFER_BIT,
    EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT,
    EGL_BUFFER_SIZE, 32,
    EGL_DEPTH_SIZE, 24,
    EGL_STENCIL_SIZE, 8,
    EGL_NONE
    };

    EGLint numConfigs;
    EGLint majorVersion;
    EGLint minorVersion;
    EGLDisplay display;
    EGLContext context;
    EGLSurface surface;
    EGLConfig config;
    EGLint contextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE, EGL_NONE };

    SDL_SysWMinfo info;
    SDL_VERSION(&info.version); // initialize info structure with SDL version info
    SDL_GetWindowWMInfo(window, &info);   
    SDL_bool get_win_info = SDL_GetWindowWMInfo(window, &info);
    SDL_assert_release(get_win_info);
    EGLNativeWindowType hWnd = info.info.android.window;

    // Get Display 
    display = eglGetDisplay(EGL_DEFAULT_DISPLAY); // EGL_DEFAULT_DISPLAY 
    if (display == EGL_NO_DISPLAY)
    {
        return EGL_FALSE;
    }

    // Initialize EGL 
    if (!eglInitialize(display, &majorVersion, &minorVersion))
    {
        return EGL_FALSE;
    }

    // Get configs 
    if (!eglGetConfigs(display, NULL, 0, &numConfigs))
    {
        return EGL_FALSE;
    }

    // Choose config 
    if (!eglChooseConfig(display, configAttribList, &config, 1, &numConfigs))
    {
        return EGL_FALSE;
    }

    // Create a 
    surface = eglCreateWindowSurface(display, config,hWnd, surfaceAttribList);
    if (surface == EGL_NO_SURFACE)
    {
        return EGL_FALSE;
    }
    context = eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs);
    if (context == EGL_NO_CONTEXT)
    {
        return EGL_FALSE;
    }

    // Make the context current 
    if (!eglMakeCurrent(display, surface, surface, context))
    {
        return EGL_FALSE;
    }
    
    SDL_Event event;

    bool running = true;
    while (running)
    {
        SDL_PollEvent(&event);
        switch (event.type) {
        case SDL_QUIT:
            running = false;
            break;
        case SDL_WINDOWEVENT:
            if (event.window.event == SDL_WINDOWEVENT_EXPOSED)
              //  redraw = 1;
            break;
        }
       
        glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
        glClear(GL_COLOR_BUFFER_BIT);
        eglSwapBuffers(display, surface);

    }
    SDL_DestroyWindow(window);
    SDL_Quit();

    exit(0);
}

Hello. SDL have SDL_AndroidGetInternalStoragePath and SDL_AndroidGetExternalStoragePath functions for accessing the device memory on Android. My application writes a lot of temporary files and I prefer to use getCacheDir according to the documentation. But SDL2 doesn't seem to have any simple function for this. So I have to use JNI to get it. Is there any reason for this?

Some start to send event of position while doing a drag n drop: (see https://github.com/libsdl-org/SDL/issues/5292 )

x11:

• doesn't report the filename. (is it possible?)

wayland:

• doesn't report the window (original flaw for all drag and drop)

I'm on an arm machine to work, Here's how I compiled it:

cmake -S /home/linaro/mnt/sdl_dev/SDL -DSDL_STATIC=OFF -DSDL_LIBC=ON -DSDL_DUMMYVIDEO=ON -DSDL_DIRECTX=OFF -DSDL_X11=OFF -DSDL_WAYLAND=OFF -DSDL_OPENGLES=OFF -DSDL_OPENGL=OFF -DSDL_VULKAN=OFF -DSDL_KMSDRM_SHARED=ON -DSDL_DIRECTFB=ON -DSDL_TEST=ON -DSDL_TESTS=ON && make -j8 && sudo make install

But the results don't seem very normal:

linaro@linaro-alip:~/mnt/sdl_dev/sdl_build/test$ ./testyuv INFO: 100 iterations in 274 ms, 2.74ms each DEBUG: No available video device ERROR: Couldn't create window: No available video device

I don't want to use gles or anything, just drm to display, how do I compile?

Hi, I am running Fedora 37 and using SDL 2.26.0 from the Fedora repo's and after some testing found the offending USB device is my Razer Blackwidow V3

ID 1532:024e Razer USA, Ltd Razer BlackWidow V3

The problem is observed when calling SDL_Init with SDL_INIT_JOYSTICK where it hangs for about 15 seconds. Unplugging the device and running resolves. I found a similar issue from 2021 (#3567) if that helps.

I was wondering if there was any appetite for adding a file name (+ extension) field to the File RWop.

I think it could be useful to get a RWop struct (from wherever) and be able to get a file name or extension out of it.

Anecdote 1 Inside of pygame, we implemented a system to do this, because the RWops get created deep in one place (with lots of Python string decoding mumbo jumbo), and then used in a fully different place, which needs the file extension (for music type or image type, for example).

I implemented this system by using one of the hidden data pointers and mallocing some room for the extension, but I couldn't figure out a way to give a "standard RWop" -- a file RWop -- a custom deletion function to clean up that memory. So we now have a different strategy to get around storing the memory in the RWop directly.

Anecdote 2 https://wiki.libsdl.org/SDL_mixer/Mix_GetMusicTitle

Please note that if the music was loaded from an SDL_RWops instead of a filename, the filename returned will be an empty string ("").

Having this field could allow SDL_mixer to get rid of this caveat in their API