The vendor-specific implementation about "EGL_MAX_PBUFFER_HEIGHT"

[Rewyear]

Hi guys

Our customer and i have a different opinion.

Customer said “In the test, that expects an error, no error occurs when the following attribute is specified in eglCreateWindowSurface().”

• #define EGL_MAX_PBUFFER_HEIGHT 0x302A
• #define EGL_MAX_PBUFFER_PIXELS 0x302B
• #define EGL_MAX_PBUFFER_WIDTH 0x302C
• #define EGL_NATIVE_VISUAL_ID 0x302E

When I checked our vendor code and I checked EGL spec.
It said

“If EGL_MAX_PBUFFER_WIDTH, EGL_MAX_PBUFFER_HEIGHT, EGL_MAX_-
PBUFFER_PIXELS, or EGL_NATIVE_VISUAL_ID are specified in attrib list, then
they are ignored (however, if present, these attributes must still be followed by an
attribute value in attrib list).”

So, I said “it can be ignored” to our customer.

But, our customer refuted with below opinion.

“The EGL Spec document above is for eglChooseConfig.
The following eglCreateWindowSurface/eglCreatePbufferSurface does not state that EGL_MAX_PBUFFER_HEIGHT is ignored”

So i refuted with below opinion.

Like “attribute_list specifies a list of attributes for the pbuffer The list has the same structure as described for eglChooseConfig” is written,
Even though that attributes is used at eglCreateWindowSurface(), I think that being ignored in eglChooseConfig is also ignored in the corresponding eglCreateWindowSurface/eglCreatePbufferSurface.

And for the official answer, i asked this phenomenon to the vendor, they said “we implemented it like your opinion(me)”

I shared our-vendor’s answer with my comment “OpenGL & EGL is vendor-specific implemented.”

But, customer don’t agree my answer and claim “we think that attribute(such as EGL_MAX_PBUFFER_HEIGHT) shouldn’t be ignored”.

Anyway, our-vendor’s OpenGL ES passed Khronos Conformance Test and is released to customer.
So, Doesn’t it don’t care if EGL_MAX_PBUFFER_HEIGHT is ignored?

I really don’t understand our customer’s opinion.
So that i want to heard the opinion of khronos forum

Best Regards
Rewyear

[Dark_Photon]

IANAL, nor am I on a Khronos board. That said, this paragraph in the EGL 1.5 Spec suggests pretty strongly that the EGL_MAX_PBUFFER_... enums are used by the EGL implementation to tell the application what limits it supports (e.g. via eglGetConfigs()). The application doesn’t get to negotiate this. It’s a given. And the quote you found indicates that these will be skipped, if found in an attrib_list provided by the client to the EGL implementation, and describes the algorithm to be used for skipping them.

EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT indicate the
maximum width and height that can be passed into eglCreatePbufferSurface,
and EGL_MAX_PBUFFER_PIXELS indicates the maximum number of pixels (width
times height) for a pbuffer surface. Note that an implementation may return a value
for EGL_MAX_PBUFFER_PIXELS that is less than the maximum width times the
maximum height. The value for EGL_MAX_PBUFFER_PIXELS is static and as-
sumes that no other pbuffers or native resources are contending for the framebuffer
memory. Thus it may not be possible to allocate a pbuffer of the size given by
EGL_MAX_PBUFFER_PIXELS.

@Rewyear

So, I said “it can be ignored” to our customer.

But, our customer refuted with below opinion.

“The EGL Spec document above is for eglChooseConfig.
The following eglCreateWindowSurface/eglCreatePbufferSurface does not state that EGL_MAX_PBUFFER_HEIGHT is ignored”

While AFAICT the spec doesn’t call out one of these opinions as invalid, I think it sides with the way the vendor implemented it and the way you expected it to work. There’s no explicit requirement for the EGL implementation to complain in the case the customer is calling out, and it says in the EGL spec that it should ignore these attrs if found, not flag an error.