D3D9 only offers 16-bit color modes (with HARDWARE switch) D3D11 prefers 10:10:10 color on 8:8:8 window with EGL_WINDOW_BIT (actually D3D11 looks unfiltered)

[Mick Pearson]

Here are just bad experiences I've had since getting started with ANGLE. First on basic backend stuff:

OPENGL: Can't seem to deal with more than one window/context. It just goes haywire and only really shows one window.

D3D11: Window resizing is always lagging one frame behind reality. The difference between the change in the window's size is filled in with black and a mysterious blue color and stays on screen permanently unless the window is redrawn twice with the same size. By contrast a non-ANGLE OpenGL (WGL) context with the same window styles (Win32) fills in the differences (gaps) with the color on the edge of the window (canvas) itself and doesn't lag behind a frame so this filler is never permanently onscreen. (The blue RGB is 4C80B2 (76,128,178) and even occurs on WS_CHILD windows that fill the frame parent window. I don't think it's coming from the parent's background. I set up a backend switch to see if OPENGL does this... I just made a single window resizable demo to test it since it wasn't working otherwise... OPENGL doesn't have this problem. Now if I can just get it to do more than one window at a time.)

D3D9: Doesn't really work. More on that next.

Next is eglChooseConfig stuff...

D3D9: Mysteriously it only considers 16-bit color color buffers. So if I ask for 8:8:8 color eglChooseConfig actually (successfully) returns 0 configs. I've tried EGL_PLATFORM_ANGLE_DEVICE_TYPE_ANGLE,EGL_PLATFORM_ANGLE_DEVICE_TYPE_HARDWARE_ANGLE and this result doesn't change. Inside ConfigSet::filter only 16-bit color attributes come up.

OPENGL: Returns 1 config matching the window (great) (expected behavior).

D3D11: Seems to return everything and the kitchen sink regardless of attributes given to it. As a result it wants to give you a 10:10:10 deep color back-buffer on an 8:8:8 system. You can manually sift through this to get 8:8:8 but it seems like EGL_WINDOW_BIT would ensure this doesn't happen.

P.S. I'm not bitter. I want to draw attention to this stuff. I hope this isn't inappropriate to this forum. It is time consuming.

[Geoff Lang]

I'm not sure about the window resizing issue.

Configs have to be generated before a Window is known.  EGL's config filtering rules are not the most intuitive, you often have to do some filtering yourself afterwards to make sure you get the config size you want.

D3D9 should expose 32-bit configs, maybe they're getting filtered for some other reaosn. OpenGL is extra finicky on Windows where you can't mix pixel formats so we can only expose a single config.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/dd9ad06e-2bc0-4cbe-a79f-6cd1d554adc8n%40googlegroups.com.

[Mick Pearson]

I ran into the "OpenGL single config" thing yesterday when I realized that the config wasn't filtered against the attributes at all because it gave me a depth buffer when I wanted none. 

Not casting aspersions it really seems like the EGL implementation (on Windows?) is very underdeveloped compared to a system that can emulate OpenGL ES. By which I mean it seems like it could work a lot better. I'm sure there's some flexibility in SetPixelFormat. I assume it supports no depth buffer for example. EGL could be much more transparent than it is (if it were designed to abstract creation of the system window object) but at the least the "config" selection system should work, I mean I shouldn't have to call SetPixelFormat myself in advance (the single config it generates comes from DescribePixelFormat, so that would be the only way) if I know I'm on WGL. This is worse on Windows because the only decent display HDC I think of to pass to ANGLE is "0" (unless it's supposed to take monitor HDCs that are kind of like virtual information querying IDs I think, and are an arcane part of Win32.) Also OPENGL currently requires that the displays all match or it can't switch contexts (https://groups.google.com/g/angleproject/c/_1Ze8aUMn4E) which may very well be a bug.

I don't know how busy the ANGLE project but EGL seems pretty basic (is it new to ANGLE?) so I would suggest the following improvements if there's someone able to work on them:

1) Don't expose configs that don't meet the attribute requirements (I know EGL upgrades some things like color depth, but it also stipulate depth buffer depth should be downgraded, i.e. reverse of the color depth stipulation.)

2) Don't expose configs that disagree with the monitor and display adaptor they will appear on. Direc3D 9 won't let me specify the color depth for its back buffer. I assume that's because it just uses the one that makes sense. I don't know how ANGLE gets the D3D11 configs it generates but it seems like they're not suited to the monitor/adaptor if the color depth varies. Really choosing a color depth doesn't even make sense for a physical display back buffer outside of dedicated full screen mode.

3) Try to make all the backends consistent (with respect to EGL.) Try to make sure configs that match the user's attributes are included. For example, with WGL it could take the attributes it's given and test them with SetPixelFormat or wglChoosePixelFormatARB. Also it can't be hard to know what parts of the  PIXELFORMATDESCRIPTOR are generally flexible and generate "configs" for them. But I've never understood why GLX uses fixed configs, unless they're really hardwired into GPU devices like. It seems like a stupid design, I don't know why EGL would adopt it unless it was the case that adaptors have some kind of config enumeration system like monitors have. In this case it seems not. So you guys have my sympathies.

[EGL is the front door to ANGLE so it's kind of the first impression we'll get when trying to test the different backends offered and see what works. Instead of feeling fleshed out the EGL interface feels thrown together, more about learning how it specifically works and doesn't work (its quirks) than just having a unified/predictable entryway into ANGLE. (I mean, I don't know, but it seems like if a config works on one backend it's very likely to work on all of them on a given system, so if I were implementing ANGLE I might try to get these parameters from a central place on the given system platform and then confirm them on the individual backends if they seem exotic or there's cause to think they would fail.)]