On Sunday 20 February 2005 13:20, Brian Paul wrote: > Adam Jackson wrote: > > I'm working on this, actually. Right now I'm doing it as an EGL->GLX > > translation layer so we can get glitz retargeted at the EGL API. Turning > > that into a dispatch layer wouldn't be too tough, particularly since a > > good bit of the engine is already written in miniglx. I've nearly got it > > to the point of being able to run eglinfo, but it seems to have uncovered > > a bug or two in the fbconfig handling. > > I actually started writing some EGL interface code a few months ago, > but haven't touched it since. Give me a day or two to clean it up. > Then let's exchange code and see what we've got.
Sounds good. > > My only complaint with EGL is that a lot of the 1.1 version is, on big > > systems, a lot of work for not a lot of gain (OES_byte_coordinates for > > example). > > Well, GL_OES_byte_coordinate is an (optional) extension. I'm not sure > we need to be concerned with it for now. Optional if you're only doing 1.0. From the webpage, describing the changes between 1.0 and 1.1 (cleaned up slightly): "New Core Additions and Profile Extensions: for the Common and Common-Lite profiles add subsets of the OES_byte_coordinates, OES_fixed_point, OES_single_precision and OES_matrix_get ES-specific extensions as core additions; OES_read_format, OES_compressed_paletted_texture, OES_point_size_array and OES_point_sprite as required profile extensions; and OES_matrix_palette and OES_draw_texture as optional profile extensions." Perversely, of these OES_draw_texture would be most useful for Xgl. > Just to be clear, I was thinking of using the EGL API with full > Mesa/OpenGL, not the ES subset. Right, same here. I'm more concerned about the API than the embedded feature set; but it would be nice to have GLES apps Just Work against Mesa. - ajax
pgpokghyGUwOB.pgp
Description: PGP signature