[vlc-devel] [PATCH] caopengllayer: do not return an error when crop/zoom/aspect/etc fail

[Alexandre Janniaux]

On 2019-10-26 18:00, Rémi Denis-Courmont wrote:
> Le samedi 26 octobre 2019, 17:07:54 EEST Alexandre Janniaux a écrit :
>> Hi,
>> 
>> On Sat, Oct 26, 2019 at 01:11:15PM +0100, Rémi Denis-Courmont wrote:
>> > Hi,
>> >
>> > The implementation ought to allocate enough resources upfront that locking
>> > cannot fail. Otherwise, how do you clean up the OpenGL context that you
>> > can't even lock??
>> I agree that it would be the sane way, but we have multiple
>> example of things that were broken by Apple during the
>> deprecation of OpenGL, and the function doesn't specify why
>> it would fail.
>> 
>> So my only source of truth is the list of error code, where
>> you can find kCGLBadAlloc. But you could have perfectly
>> valid other issues from outside of this module like:
>> + kCGLBadConnection
>> + kCGLBadWindow
>> + kCGLBadDisplay
>> + kCGLBadDrawable
> 
> Those are all specific variants of invalid argument errors, that only a 
> buggy
> app can trigger. I'm all for handling possible errors, to the extent 
> they're
> actually handlable and handled. Checking for an error code and skipping 
> a bit
> of code is rarely proper error handling.
> 
> IMO, bullshit "defensive" programming is much worse than assertions or 
> simply
> not handling errors, as it solves nothing; it only makes debugging 
> harder.

Let's say the list I gave correspond to your description.

kCGLBadAlloc is still there. And I don't know a lot about
CGL, but in EGL you can call eglReleaseThread, which will
release per-thread state. After a call like this, any EGL
command, even eglGetError, will trigger a new allocation
for the state.

Do you have any hints that would highlight the fact that
Apple does give a guarantee about not doing things like
that in its backend ?

Regards,
-- 
Alexandre Janniaux
Videolabs