Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release.

Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon.

If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks.

Thanks!

--ryan.

Bug in the render batch code?

Is there a way to disable batch rendering so I could test? Is the batch rendering also used with the software renderer?

You can disable batching with:

SDL_SetHint(SDL_HINT_RENDER_BATCHING, "0");

Also, could you attach a test-case maybe?

(In reply to Sylvain from comment #4)
> You can disable batching with:
> 
> SDL_SetHint(SDL_HINT_RENDER_BATCHING, "0");
> 
> Also, could you attach a test-case maybe?

It's possible this is the same thing as Bug #4411?  (and it's possible we've since fixed that bug, but that's unclear).

I don't think I'm going to be able to get a Python script to run on an Android device without a disproportional amount of effort.   :/

--ryan.

Okay, I just tried SDL_SetHint(SDL_HINT_RENDER_BATCHING, "0"); but sadly that build always instant crashes for me!

Before it crashes, I run into this assert:

Assertion failure at SW_RunCommandQueue (SDL/src/render/software/SDL_render_sw.c:596): viewport != ((void*)0)

This is interesting because I request a renderer like this:

self._renderer = \
    sdl.SDL_CreateRenderer(self._sdl_window, -1,
        sdl.SDL_RENDERER_ACCELERATED)

... so I shouldn't actually be using a software renderer. Nevertheless, whatever is going on, it seems like running without render batching is in some way broken right now

Sorry, I forgot: I'm a few commits back on hg though, I'll retry with the latest tip right now. Maybe that crash is fixed with that, I'll keep you updated just give me an hour or so

(In reply to Jonas Thiem from comment #7)
> Sorry, I forgot: I'm a few commits back on hg though, I'll retry with the
> latest tip right now. Maybe that crash is fixed with that, I'll keep you
> updated just give me an hour or so

Yeah, that assertion was fixed very recently, in https://hg.libsdl.org/SDL/rev/32839175c0e4

SDL_RENDERER_ACCELERATED is ignored (all the flags, actually) if you request a specific renderer with the hint. I'm not entirely sure if that should be a bug or not.

(Requesting a specific renderer also disables batching unless you force it on with the hint, because we don't otherwise know if you plan to interact with the lower-level graphics API and expect it to flush everything to the GPU immediately, like it did in 2.0.8 and earlier, before making your own OpenGL or whatever calls.)

--ryan.

Removing target-2.0.10 from this. If anyone has had a chance to retest, there's still a small window where further fixes can go into 2.0.10, if any are still needed.

--ryan.

Ok, I just did the following test:

1. I screenshotted what was going on with the wrongly colored lines (like notably colored wrong, colorless gray instead of red!)

2. I viewed the screenshot in the gallery on-device (on the Android phone) - also wrong

3. I detached the HDMI cable. Suddenly, the screenshot looks CORRECT (all red lines are red)

4. I sent the screenshot to myself via e-mail and looked at it on my laptop, also correct

5. When I view the screenshot in the gallery on-device and plug the cable back in, the lines go back nonsense in colors

I conclude from this that this is some very absurd device bug that messes up certain patterns in color completely when the HDMI cable is attached. Since it occurs in the normal gallery app and with an image that is clearly static, this appears to be broken at a fundamental firmware level with the "Gemini PDA" Android phone firmware, and not an SDL2 bug.

Sorry for all the ticket noise, and thanks so much all the help with locating the culprit!

Thanks for the update!