Re: OpenGL context without AppKit

[Niels Grewe]

Am 28.01.2012 21:35, schrieb Ivan Vučica:
> 
> 
> On Sat, Jan 28, 2012 at 14:16, Niels Grewe <address@hidden
> <mailto:address@hidden>> wrote:
> 
> 
>     One thing we should keep in mind is that in the long run, we also want
>     to support embedded platforms (hell, they're probably the primary
>     target, aren't they?), where we only have OpenGL-ES and probably no
>     X-server. So maybe we should evaluate going right to EGL here, which is
>     a much cleaner and platfrom independent approach to the same thing. I'm
>     not quite sure how stable EGL support for desktop X servers is (Debian
>     has a libegl1-mesa package in testing, though), but on my Efika (which
>     uses proprietary drivers for everything), it took very little effort to
>     come up with a POC that shared a surface between OpenVG (used by Opal
>     via cairo) and OpenGL-ES such that it could be animated while Opal was
>     drawing to it. I'll try to dig it up if you're interested.
> 
> 
> Hi,
> 
> definitely. I'm counting on supporting GLES. I'm not sure it's sensible
> to target solely GLES. Most (if not all) of CoreAnimation code will be
> shared between GL and GLES, and creation of the context is platform
> specific, anyway, isn't it?
> 
> GLES support on desktops will be flaky at best, missing at worst (see
> Win32). Targeting both GL and GLES is not difficult.
> 
> Am I wrong? :-)

No, you're quite right :-) The point about EGL is that it's not tied to
OpenGL-ES or any specific windowing system. Instead, it supports all of
OpenGL, OpenGL-ESv(1|2) and OpenVG on whatever native windowing
environment you throw at it. Basically, instead of having platform
specific calls glXMakeCurrent() or wglMakeCurrent() to tell OpenGL where
to draw to you get eglMakeCurrent() and pass it an EGLSurface which can
be (among others) an off-screen buffer or a native window that you'd get
via eglCreateWindowSurface(). So the platform specific stuff is already
abstracted away for you long before you actually start drawing. The
ability to mix OpenGL(ES) and OpenVG transparently is merely the icing
on the cake ;-) I hope I could clarify my suggestion a bit.

Cheers,

Niels