have we considered glew library?

[Paweł Hajdan, Jr.]

I see a lot of custom wrappers/bindings code we have in ui/gl and gpu directories.

Have we considered using glew library (http://glew.sourceforge.net/) for that purpose? If yes, what was lacking in it? If no, what do you think about switching to it? (I can do the work)

The rationale is that GLEW is packaged by Linux distros, so we can more easily re-use their system copy as an option (Google Chrome would use a bundled copy of glew).

[James Robinson]

On Mon, Nov 19, 2012 at 3:36 PM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

I see a lot of custom wrappers/bindings code we have in ui/gl and gpu directories.

Have we considered using glew library (http://glew.sourceforge.net/) for that purpose? If yes, what was lacking in it? If no, what do you think about switching to it? (I can do the work)

I don't think we are desperate for new third party dependencies in these locations.  Does it solve problems that we've had in these areas?  Could we simplify our existing code or avoid bugs that we've had in our bindings?  Can you point to specific incidents that you think could be avoided with GLEW?

 

The rationale is that GLEW is packaged by Linux distros, so we can more easily re-use their system copy as an option (Google Chrome would use a bundled copy of glew).

That's not a project goal.  This would have to be an improvement on its own merits to be worthwhile.

- James 

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Paweł Hajdan, Jr.]

On Mon, Nov 19, 2012 at 3:40 PM, James Robinson <jam...@google.com> wrote:

On Mon, Nov 19, 2012 at 3:36 PM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

I see a lot of custom wrappers/bindings code we have in ui/gl and gpu directories.

Have we considered using glew library (http://glew.sourceforge.net/) for that purpose? If yes, what was lacking in it? If no, what do you think about switching to it? (I can do the work)

I don't think we are desperate for new third party dependencies in these locations.

Couldn't resist: we keep adding things to third_party/ at a huge rate. I know this is off-topic here, please ignore. ;-)

 

Does it solve problems that we've had in these areas?  Could we simplify our existing code or avoid bugs that we've had in our bindings?  Can you point to specific incidents that you think could be avoided with GLEW?

Well, generally GLEW does a very similar thing as these bindings. However, Gregg Tavares (gman) pointed out to me many problems with GLEW, including GLES support, ANGLE support and others.

I am now definitely sure we can't use GLEW, and that's what I was trying to determine in this thread.

 

The rationale is that GLEW is packaged by Linux distros, so we can more easily re-use their system copy as an option (Google Chrome would use a bundled copy of glew).

That's not a project goal.  This would have to be an improvement on its own merits to be worthwhile.

Just to clarify: generally where there is an existing library that does what you're trying to do, it is worthwhile to re-use it instead of writing the code from scratch. GLEW was pretty close here, but I just realized it does not solve all problems the bindings in Chrome have to solve.

[Al Patrick]

I originally used glew. I changed it to what we have in ui/gl for the reasons Gregg outlined

- no GLES2 support

- no support for our non-standard extensions

- we'd have to fork it to add our GL extensions

- our bindings expose a consistent GLES2 API everywhere. Eg if it's regular GL under the hood you can still call glBindFramebuffer instead of glBindFramebufferEXT everywhere and it is remapped behind the scene.

So although they are somewhat similar, glew would not be a straightforward drop-in replacement.