Previously, when we started a worker operation that eventually throws an exception (e.g. due to the tile not being parseable), and then enqueue another worker operation while the first one is processing, we treated the worker as idle once the first operation's error callback fired, even though the second operation was still in progress. Due to our use of coalescing, I was unable to come up with a reliable test since we'd need to reproduce the behavior described above, which is timing dependent.
Since 9a9408e811, we marked tiles as non-renderable if an error occured. This lead to situations where a tile was loaded + parsed successfully, then a revalidation attempt occured (e.g. because the resource was stale) which failed. In this case, we used to mark the tile as non-renderable although we could've used the perfectly parsed (stale) resource.
Previously, when we started a worker operation that eventually throws an exception (e.g. due to the tile not being parseable), and then enqueue another worker operation while the first one is processing, we treated the worker as idle once the first operation's error callback fired, even though the second operation was still in progress. Due to our use of coalescing, I was unable to come up with a reliable test since we'd need to reproduce the behavior described above, which is timing dependent.
Since 9a9408e811, we marked tiles as non-renderable if an error occured. This lead to situations where a tile was loaded + parsed successfully, then a revalidation attempt occured (e.g. because the resource was stale) which failed. In this case, we used to mark the tile as non-renderable although we could've used the perfectly parsed (stale) resource.
Otherwise it errors with, "cannot initialize a variable of type 'BOOL' (aka 'signed char') with an rvalue of type 'id _Nullable'."
This doesn't seem like it should be necessary.
This reverts the manual layout triggered by KVO approach in favor of a constraints based approach that the KVO method had previously replaced. Although the manual layout approach worked well in most cases and was cleaner in that it did not manipulate any containing views in the app space, using KVO on UIViewControllers has proven to be dangerous.
This also updates the gitshas for KIF and OHHTTPStubs to unbreak UI tests that verify these related changes are working.
This also adds an ornament constraint system for iOS 11+
A bogus source file path was causing contention between two resources. As a consequence, Transifex spammed the project’s watchers daily about changes that didn’t occur.
When a texture is deleted, it is as if all texture units to which that texture object is bound are rebound to texture object zero. Therefore it's the *bindings* that need to be dirtied, not the active texture unit.
