servo/gleam

Generated OpenGL bindings and wrapper for Servo.

gleam's Issues

glCopyBufferSubData missing?

It seems that the current Gl trait is missing a copy_buffer_sub_data() function, which corresponds to the glCopyBufferSubData function - this is an important function necessary for deep-cloning vertex / index buffers without making roundtrips to the CPU. Is it intentional that this function has been left out or is this a bug?

load_with functions should be unsafe

Revive link to GL library.

The link to GL library was removed by #106, since gleam does not call linked GL functions. But it is necessary to revive it. Dependent crates expects that gleam does link to GL library to avoid double linking error like servo/surfman#84.

Servo GUI?

Does this imply the Servo GUI will be OpenGL?
That'd be marvellous. Most "toolkits" are huge and bloated. OpenGL ES is the best alternative, I think. OpenGL coming right after it.

get_shader_info_log truncates logs at 1024 characters

From the spec:

The size of the buffer required to store the returned information log can be obtained by calling glGetShaderiv with the value GL_INFO_LOG_LENGTH.

Protect master branch

get_program_iv is memory unsafe with GL_COMPUTE_WORK_GROUP_SIZE

According to http://docs.gl/es3/glGetProgramiv params will contain an array of three integers, unlike all of the other constants that can be passed to this function.

get_vertex_attrib_iv is memory unsafe with GL_CURRENT_VERTEX_ATTRIB

It only stores a single integer, but the spec says it returns four.

Stack overflow during compilation

I'm not 100% sure whether this issue belongs here or at the cargo repo, however this seems to be the only crate for which this is occurring on this system.

I'm getting the following stack overflow while attempting to compile this crate:

Joshuas-MacBook-Air:gleam joshuabatty$ cargo check
    Updating crates.io index
   Compiling khronos_api v3.0.0
   Compiling cfg-if v0.1.6
   Compiling xml-rs v0.8.0
   Compiling log v0.4.6
   Compiling gl_generator v0.10.0
   Compiling gleam v0.6.8 (/Users/joshuabatty/Documents/Rust/gleam)

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
error: Could not compile `gleam`.

Caused by:
  process didn't exit successfully: `rustc --crate-name gleam src/lib.rs --color always --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C metadata=56b5b8b73780c6f2 -C extra-filename=-56b5b8b73780c6f2 --out-dir /Users/joshuabatty/Documents/Rust/gleam/target/debug/deps -C incremental=/Users/joshuabatty/Documents/Rust/gleam/target/debug/incremental -L dependency=/Users/joshuabatty/Documents/Rust/gleam/target/debug/deps` (signal: 6, SIGABRT: process abort signal)

System:
MacBook Air (Mid 2011)
MacOS 10.10.5

I'm not yet sure whether this is specific to this machine or not. Is it possible that this old macbook air has a lower stack size limit?

Occurs on both 1.33.0-nightly and 1.31 stable version of rustc and cargo.

I originally bumped into this in a downstream repo that uses glutin, which uses this. Still currently trying to find a workaround.

Gl::buffer_data_untyped should be unsafe

It takes a raw pointer.

Run-time selection between GL and GLES

For Gecko integration, we need to optionally run through Angle, which requires GLES context. This is controlled by preferences, so the decision is made at run time.

GL_OES_EGL_image_external support

I'm trying to use a new target TEXTURE_EXTERNAL_OES in windows platform. It comes from gles. We use ANGLE gl context at windows platform. And the ANGLE is gles.
I'm not sure what I should do here. Should I just add that constant value im gleam?

The spec for this extension:
https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt

Implement glDrawBuffers/GL::draw_buffers Binding

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawBuffers.xhtml
I'd like to use this for rendering to textures, if there's no way to bind the GL_COLOR_ATTACHMENT as a fragment shader target without using it.

I can put up a pull request for this.

get_integer_v/get_integer_64v/get_integer_iv/get_integer_64iv/get_boolean_v/get_float_v are memory unsafe

They all provide a mutable pointer to a single value, but some parameters like GL_BLEND_COLOR are specified to write more than one value. This API implementation is wildly unsafe in its current form.

0.13.2 has semver breaking-changes

0.13.2 has additions to the Gl trait, and that breaks semver compatibility promises. It should actually be 0.14.0, and 0.13.2 should be yanked.

Add mode that asserts when glGetError returns non-zero after any GL call

Making this configurable at build time would make it much nicer to debug mysterious errors.

Ensure slice size constraints in uniform functions.

Some uniform functions asume that multiples of x elements are passed to them.

It could be worth it to add debug_assert!s to those functions to ensure they're been called correctly.

It's not such a big deal (in the sense that it doesn't cause unsafety), because of the round-down in integer division, but it's nice to have to catch bugs.

In #78 I pinged @glennw, but since there were no response, it was merged as-is.

Rename viewport to set_viewport and get_viewport to viewport

…But let's wait to have a legit reason to make a breaking bump to do that.

Reduce duplicated code between GLES and GL

There is some nontrivial logic duplication happening. It would be nice to extract that into shared helpers that accept GL function pointers to call.

Avoid dynamic dispatch

As of #106, we have a Gl trait that is passed around in Rc pointers. This involves dynamic dispatch on every function call, which is undesirable. It would be great to remove this overhead.

3D textures disabled on Android

#[cfg(not(target_os="android"))]
pub fn tex_image_3d(target: GLenum,
...
#[cfg(not(target_os="android"))]
pub fn copy_tex_sub_image_3d(target: GLenum,
...

They are supported on GLES 3.0, so I believe gleam should be exposing them on Android.

related - servo/webrender#487

Add gl type detection function

This issue is part of #99. To make runtime gl type selection works, we need to know current GL type is GL or GLES. It could help even when gl type is determined during build time. I assume the function and enum is like the following. Is it OK for gleam?

#[derive(Debug, PartialEq)]
pub enum GlType {
Gl,
Gles,
}

#[cfg(not(target_os="android"))]
pub fn gl_type() -> GlType {
GlType::Gl
}

#[cfg(target_os="android")]
pub fn gl_type() -> GlType {
GlType::Gles
}

More background info could be in https://bugzilla.mozilla.org/show_bug.cgi?id=1325911

Turn GLES profile selection into a feature

The code is currently using the target_os="android" check to see if GLES needs to be set up instead of desktop GL. We need to turn it into a compile feature in order to support Angle on desktop.

Combined GL + GLES defines

Currently, as of #106, we mix together GL and GLES specifications in order to generate the bindings having defines from both APIs. It would be great to limit that union of specs to defines only and avoid generating the function signatures in ffi.

Add newtypes for different resources

I encountered a problem in Servo where we were calling delete_buffer on the result of gen_textures, and the effect was surprisingly subtle. This could be avoided if APIs like delete_buffer accepted strong types instead of integers.

declare_gl_apis! macros doesn't allow us to add default function implementations

For #228, I would have liked to add default (empty) implementations of the newly added functions. This would be nice because a) the extension I'm exposing is GLES-only, so does not need a GlFns implementation. And b) currently every time we expose a new API to the Gl trait it's a breaking change and we have to bump the semver, and in gecko we need to add an impl to our swgl trait, even when it won't be used.

Unfortunately, trying to add a default impl currently results in a compilation error due to the declare_gl_apis macro:

error: no rules expected the token `{`
   --> src/gl.rs:765:113
    |
81  | macro_rules! declare_gl_apis {
    | ---------------------------- when calling this macro
...
765 |     fn start_tiling_qcom(&self, x: GLuint, y: GLuint, width: GLuint, height: GLuint, preserve_mask: GLbitfield) {
    |                                                                                                                 ^ no rules expected this token in macro call
    |
note: while trying to match `;`
   --> src/gl.rs:83:106
    |
83  |     ($($(unsafe $([$garbo:expr])*)* fn $name:ident(&self $(, $arg:ident: $t:ty)* $(,)*) $(-> $retty:ty)* ;)+) => {
    |

Please make a version break every time you add functions to the `Gl` trait

I've now gotten this error here: fschutt/azul#203 (comment) - which happens because I have a custom implementation of the Gl trait for providing a "virtual" OpenGL driver for unit-testing purposes. gleam 0.6.20 added three new functions; gen_vertex_arrays_apple, delete_vertex_arrays_apple, bind_vertex_array_apple. You can close this issue if you've read it, but I just wanted to say it - cargo relies on semantic versioning to be done properly and this is at least the fifth time that my code breaks because some dependency didn't stick to semver. Sadly, I'm not able to lock down the version of gleam for a library if gleam doesn't adhere to semver, because cargo ignores Cargo.lock files of libraries. While this is more of a problem with cargo, for the meantime it would be nice to not release new versions of gleam under 0.6 if they aren't actually compatible with the old Gl trait.

Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 gleam developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @glennw
• @ecoal95
• @SimonSapin
• @metajack
• @mbrubeck
• @larsbergstrom
• @Manishearth
• @robn
• @pcwalton
• @Ms2ger
• @jdm
• @simartin
• @dzbarsky
• @nox
• @frewsxcv
• @akiss77
• @dmarcos
• @eljay
• @meh
• @mitchmindtree

get_program_info_log truncates log at 1024 characters

According to the spec:

The size of the buffer required to store the returned information log can be obtained by calling glGetProgramiv with the value GL_INFO_LOG_LENGTH.