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 4633 - Setting SDL_BLENDMODE_BLEND, a render draw color and then using SDL_FillRect (in that order) might flicker in color on Android
Summary: Setting SDL_BLENDMODE_BLEND, a render draw color and then using SDL_FillRect ...
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: HG 2.1
Hardware: ARM Android (All)
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-18 11:32 UTC by Ellie
Modified: 2019-08-06 06:40 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ellie 2019-05-18 11:32:01 UTC 
Setting SDL_BLENDMODE_BLEND, then a render draw color, and then using SDL_FillRect (in that order) will sometimes flicker in color on Android. What I'm seeing is that it flickers randomly between other colors also used in the same frame for other rectangles before, and it ends up with a different wrong (or sometimes the correct) color on each redraw. If I redraw less it flickers less, so this is directly correlated to the actual draw

This bug is really weird, because it occurs in BOTH software & gpu accelerated mode (so not a gpu driver bug...?) but only under very specific conditions:

AFFECTED CODE:

This is the exact rectangle drawing code that flickers:

https://github.com/wobblui/wobblui/blob/a81afd6fa5ac28f25631d4c65d0faa87ad00c1be/src/wobblui/gfx.pyx#L123

CONDITIONS WHEN IT HAPPENS:

Only on Android (tried both 7.1 and 8.1) and only if an external HDMI screen is attached with mirroring output to it (???) and then only SOME rectangles drawn with this function are affected by this, and it's broken for the software renderer as well...??? It works correctly on Android always when there's no external screen, also on Linux and Windows always.

Even though I have no idea what is going on, I don't even know how to detect HDMI mirroring in my app code (so how could it behave any different as a response, intentional or not?) and it's occurring with the software backend as well, which leads me to believe this might be an SDL2 bug
Comment 1 Ryan C. Gordon 2019-05-18 18:48:54 UTC 
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.
Comment 2 Sam Lantinga 2019-06-08 20:27:21 UTC 
Bug in the render batch code?
Comment 3 Ellie 2019-06-08 20:38:51 UTC 
Is there a way to disable batch rendering so I could test? Is the batch rendering also used with the software renderer?
Comment 4 Sylvain 2019-06-11 14:33:02 UTC 
You can disable batching with:

SDL_SetHint(SDL_HINT_RENDER_BATCHING, "0");

Also, could you attach a test-case maybe?
Comment 5 Ryan C. Gordon 2019-06-12 03:39:36 UTC 
(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.
Comment 6 Ellie 2019-06-16 20:26:17 UTC 
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
Comment 7 Ellie 2019-06-16 20:27:23 UTC 
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
Comment 8 Ryan C. Gordon 2019-06-17 05:17:38 UTC 
(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.
Comment 9 Ryan C. Gordon 2019-07-02 16:59:03 UTC 
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.
Comment 10 Ellie 2019-08-03 22:50:18 UTC 
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!
Comment 11 Sam Lantinga 2019-08-06 06:40:25 UTC 
Thanks for the update!