The lock is in place to enforce that `async` is not accessed if the request has been, cancelled. Therefore it's not necessary to hold the lock beyond setting cancelled to true, and in fact it's unsafe to so: if this is the last remaining shared reference, `delete this` will destroy the mutex. If the lock was held, it would then be orphaned.
This eliminates the reliance on ThreadContext to provide GLObjectStore, and statically enforces that GL cleanup functions happen only when GLObjectStore::performCleanup is called.
With the elimination of the Map thread, this becomes important because there may be multiple GLObjectStore's per-thread, and Map will need to ensure that the correct context is active when calling GLObjectStore::performCleanup.
These tests are intended to reflect how someone using the custom layer feature might actually write their callbacks. Therefore the callbacks should not use mbgl-specific classes.
This reverts commit 69112a2a09.
People are used to dragging frameworks into the Linked Frameworks and Libraries section, but the SDK only works when embedded inside the application.
Fixes#4011.
Texture pool now allocates a block of 64 textures per time. Each block
contains a TextureObject which handles GL object lifetime. Blocks can be
added or removed according to the following rules:
1. If pool is empty, created a new block upon first call (lazy load);
2. Iterate blocks to find an available texture ID:
- If found, remove that from the list of available IDs for that block
and return its ID.
- Othewise, allocate a new block and grab an available ID from that.
3. When releasing a texture ID, check if the associated block is free.
If no IDs are currently in use, then abandon its TextureObject and
remove the block from the pool.
error: converting ‘false’ to pointer type for argument 1 of ‘char
testing::internal::IsNullLiteralHelper(testing::internal::Secret*)’
[-Werror=conversion-null]
If we don't do this, we can activate a request twice.
The issue here is that we use memory address as the 'key'. So if
we destroy a request, another request might take the same memory
address, or the same 'key'.
The entry at 'pendingRequests' survives the 'cancel()' and is
ultimatelly removed at 'activatePendingRequest()'. This is fine
unless a request is created using the same 'key' before we call
'activatePendingRequest()'.
The check if the request was canceled at 'activatePendingRequest()'
will be no longer valid, activating the request. At the same time
the request will be activated again by the task scheduled at the
constructor of the 'OnlineFileRequestImpl' class.
