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 3373

Summary: OpenGL implementation differences of glDrawTexfOES
Product: SDL Reporter: Simon Hug <chli.hug>
Component: renderAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: amaranth72
Version: HG 2.0   
Hardware: ARM   
OS: Linux   
Attachments: glDrawTexfOES test.
Screenshot of gldrawtexfoes_test.c on Intel hardware.
Screenshot of gldrawtexfoes_test.c on the Raspberry Pi.
Patch that disables glDrawTexfOES path for the RPI driver.

Description Simon Hug 2016-06-23 13:21:26 UTC 
Created attachment 2509 [details]
glDrawTexfOES test.

It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping.

The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough.

I don't know about the other vendors, but I attached a program that others could test on AMD and NVIDIA hardware.

[1] https://www.khronos.org/registry/gles/extensions/OES/OES_draw_texture.txt
Comment 1 Simon Hug 2016-06-23 13:22:34 UTC 
Created attachment 2510 [details]
Screenshot of gldrawtexfoes_test.c on Intel hardware.
Comment 2 Simon Hug 2016-06-23 13:23:02 UTC 
Created attachment 2511 [details]
Screenshot of gldrawtexfoes_test.c on the Raspberry Pi.
Comment 3 Simon Hug 2016-06-23 13:25:41 UTC 
Created attachment 2512 [details]
Patch that disables glDrawTexfOES path for the RPI driver.

If it turns out that the Raspberry Pi is the only one doing something weird, I propose disabling the glDrawTexfOES path for it. I could not observe a performance difference anyway.
Comment 4 Alex Szpakowski 2016-06-23 15:01:49 UTC 
Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).
Comment 5 Sam Lantinga 2016-10-01 17:43:34 UTC 
I opted to remove that code path. Thanks!
https://hg.libsdl.org/SDL/rev/8e4a030053c2