Re: OpenGL context without AppKit

[Ivan Vučica]

On Sat, Jan 28, 2012 at 22:06, Niels Grewe <address@hidden> wrote:

> 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.

Unfortunately, upon further examination, it seems that this is not correct: EGL is solely for creating OpenGL ES contexts, not for creating OpenGL contexts. See, for example:

  http://stackoverflow.com/questions/7017239/what-are-the-relations-between-egl-and-opengl

In any case, I also played with OpenGL ES2 yesterday, and I believe the best way to go would be to plan the renderer around OpenGL ES2, and simply kick out those minimal shaders that we are required to have when it comes to OpenGL ES1, and perhaps OpenGL if they are unsupported.

Aside from having serious API limitations that would force proper design of the renderer, designing around ES2 would eventually allow applying various filters to the layers. (I don't know how CoreImage filters work exactly, but if they can be done on the GPU, they probably should be done on the GPU.)

On Sat, Jan 28, 2012 at 22:25, Eric Wasylishen <address@hidden> wrote:

Hi Ivan,

One idea I've thought of is turning the display server part of -back in to a standalone framework that doesn't depend on gui, then making gui depend on this new display server framework + opal. I think it would be relatively straightforward.

This would let you use the display server without depending on -gui, and make the display server easier to test in isolation (one of my complaints with the current -back is that it is hard to test; it's only tested indirectly through gui.)

That's the perfect solution. I suspect there are not too many dependencies, but unfortunately, there are still too many of them for me to crunch through. 

-- 
Ivan Vučica - address@hidden