OpenGL bindings for Servo
servo / gleam Goto Github PK
View Code? Open in Web Editor NEWGenerated OpenGL bindings and wrapper for Servo.
License: Other
Generated OpenGL bindings and wrapper for Servo.
License: Other
OpenGL bindings for Servo
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.
…But let's wait to have a legit reason to make a breaking bump to do that.
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.
There is some nontrivial logic duplication happening. It would be nice to extract that into shared helpers that accept GL function pointers to call.
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.
Making this configurable at build time would make it much nicer to debug mysterious errors.
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.
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.
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.
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?
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
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.
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.
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.
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!
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.
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
.
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.
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.
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.
It takes a raw pointer.
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.
#[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
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)* ;)+) => {
|
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.
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.
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
It only stores a single integer, but the spec says it returns four.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.