* Complete wasm backend memory mgmt, extract common glow code
Similar to 3e8d2d7d, but for the wasm backend.
Also takes a pass at consolidating some of the common code between the
glow-native and glow-wasm backends. At this point, the backends just
diverge in their window handling, and the data types of their OpenGL
data types (e.g. vertex_buffer.id is WebBufferId vs. uint32 on native)
* glow impls share prerender innards
* coalesce vertex/buffer types
* minimize diff
* clarify module naming
Without this change, the screen was blank when using the glow backend on macos.
Some debugging traced it down to the shader attribute configuration.
@dabreegster suggested trying to declare a newer version of the shader
language which supports the syntax for explicit attribute layout, which
fixed it.
Specifically, before this commit, this diff was interesting on macos:
diff --git a/ezgui/src/backend_glow.rs b/ezgui/src/backend_glow.rs
index 2046bccd..f834a4fa 100644
--- a/ezgui/src/backend_glow.rs
+++ b/ezgui/src/backend_glow.rs
@@ -244,31 +244,7 @@ impl PrerenderInnards {
glow::FLOAT,
false,
stride,
- // WTF: this offset seems correct, but on macos (OpenGL 4.1)
- // a blank screen is rendered.
- //
- // To debug, I've hardcoded a color assignment in the fragment shader.
- //
- // What's fascinating is that, even if we don't use this second "style"
- // input for anything, the mere act of passing it in with the expected
- // offset causes all the geometries to not be visible.
- //
- // That is:
- // - with a hardcoded color in the fragment shader
- // - set offset `0` here (which is surely wrong?)
- // - I can see the correct shapes with my hardcoded color
- //
- // - with a hardcoded color in the fragment shader
- // - set offset `2*size_of(f32)` here (which should be right)
- // - I'd expect to see the correct shapes with my hardcoded color
- // - But instead I can no longer see any shapes on the screen
- //
- // So it seems like something about setting the offset on this second attribute
- // configuration is corrupting our vertex data, even if we never read from that
- // attribute data.
- //
- // 2 * std::mem::size_of::<f32>() as i32,
- 0
+ 2 * std::mem::size_of::<f32>() as i32,
);
new trips, then seeing the impact they'll have on the normal weekday
scenario. So how much externality would be caused by a bunch of new
trips if some building is built?
Demo showing the whole flow: https://youtu.be/adpED0KGQ7Q. Why do those
few trips at the beginning impact some later trips so much? Who knows.
Likely parking spots get gobbled up.
a zone per hour. This is part of support for some kind of congestion
charging experiments. This step just rearranges the data to define the
cap and makes a UI to edit it. Not enforcing the cap yet.
- Need to draw a background underneath the curved text
- Sometimes the text is "upside-down" relative to what's expected; we
should be able to reverse the polyline sometimes to deal with that. But
when?
one of the outbound roads. This was motivated by one particular example
in downtown, and per screenshot tests, doesn't have regressions
elsewhere. Also improves a few cases in montlake.
"compressing" empty space between intersections. The result is a little
unexpected sometimes, but it's an improvement over the previous thing.
@michaelkirk suggested a variation in Slack that I'll try soon.
- wire up the flag to skip building contraction hierarchies in one-shot
importer. 406s to import london without, 230s by skipping CH
- lazily render zoomed parking lot details. 72s and laggy X11 mouse
before, 42s and no GPU melting after
- add my script for stress-testing the importer
trips as a Scenario to later re-run. This is useful for quickly defining
"test cases" for development, and it's a start to a UI for letting
players specify (and eventually share) traffic patterns they define.
85ad194d introduced a patched winit.
In the glium build, we were pulling in a second version of winit (the
unpatched version, via glutin). This caused conflicts between the data
types, breaking the build.
Apparently the proper way to specify a patch like this, usable by
transitive dependencies, is via cargo's "patch" specifiers
combining primitive transitions into sequences.
Brief context on the state/transition system: The game crate is
organized as a stack of states, with the topmost one being active.
Transitions manipulate this stack. For example, the stack might look
like: [main menu, sandbox mode, edit mode, traffic signal editor, signal
picker]
watching https://www.openstreetmap.org/node/53214134 on the weekday
scenario. At some point, an arrow polygon with an inner ring is scaled
down, collapsing its points so much that the ring becomes invalid.
when allowing a car to start a turn. It causes
https://github.com/dabreegster/abstreet/pull/276#discussion_r470269394
and also the lakeslice scenario to gridlock (a regression that began a
few weeks ago). But keep the flag on for now, to keep the montlake
scenaro running at least.
https://dabreegster.github.io/abstreet/trafficsim/gridlock.html has
notes about the many different causes and in-progress fixes for
gridlock. This experiment hasn't been explained very well yet, but
roughly it treats a cluster of traffic signals as one, so that once a
vehicle gains access through the first light, they guarantee immediate
access through the entire sequence. This interacts with the "don't block
the box" behavior (don't start a turn if you might get stuck in the
intersection) strangely.
While attempting to get this rollback to work, I also had to manually
redraw the traffic lights for a few manually specified intersections.
They became out-of-date a few weeks ago when I cleaned up the OSM
geometry upstream and the referenced IDs changed, and I hadn't bothered
to re-time the signals. Luckily, with the new multi-signal editor,
redrawing the timing was much easier than originally!
Regenerated all data and lots of bus routes vanished. Plan to get back
to that project soon.
