92 releases (38 breaking)
|0.38.0||Nov 28, 2022|
|0.36.0||Jul 22, 2022|
|0.32.3||Feb 27, 2022|
|0.32.0||Nov 17, 2021|
|0.0.11||Oct 28, 2019|
#118 in WebAssembly
3,420 downloads per month
Used in dominator_helpers
awsm_web is primarily used as a building block for other crates in the awsm ecosystem.
The approach with this library is similar in spirit to gloo - that is to say, it bridges the gap between the auto-generated WebIDL-powered bindings web-sys provides, and the type of code we'd typically consider a real starting point in web apps.
Features are heavily gated keep dependencies minimal. The default is for no features to be enabled, but the
all feature will turn them all on (except those that are only meant for debugging like
The goal is to keep it very low level and low-cost abstraction that is almost universal. However, almost universal is not without opinions. For example, the webgl wrapper provides a lazy caching mechanism for all string lookups (including ubo offsets and texture samplers) and stores local state to avoid making unnecessary gl calls.
In terms of whether to use strings or precalculated integers:
uniforms: you can't know those in advance, you have to get them via a web api call that takes a string
uniform buffer objects: you can sorta set and calculate it in advance, but it's very error prone and fragile
sampler index: can be set in advance but requires syncing with the uniform value
attributes: can be set in advance, either through shader code or web api
Therefore, for everything other than attributes, it's best to use strings everywhere - after the first call, it's merely a local cache lookup.
Note also that there is a global registry for specifying ubo and attribute locations in advance of any shader code
It happens in a couple levels
The first is very thin wrappers over the native web_sys types, added as extension traits on the contexts (both webgl1 and 2). These can be used directly on the contexts and are prefixed
awsm_*. At this level, no additional state is maintained.
Then, the WebGlRenderer wrappers (also for 1 and 2) contain all the state and caching stuff mentiond above. For ease of use, many of the functions that could be called on the context directly are re-exported on the renderer without the