* Unlocked a mutex after modifying the variable the mutex was meant for.
This fixes an issue where mounting bundles in the Editor was causing the Editor to freeze up, because the following line, m_levelOpenEvent.Signal, resulted in another attempt to lock that same mutex.
Signed-off-by: AMZN-stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
* Added a comment describing why the unlock is necessary.
Signed-off-by: AMZN-stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
- Replace AZ_TRAIT_MAX_JOB_MANAGER_WORKER_THREADS with AZ_TRAIT_THREAD_NUM_JOB_MANAGER_WORKER_THREADS that allows the number of threads created by the job manager to be set directly.
- Add AZ_TRAIT_THREAD_NUM_TASK_GRAPH_WORKER_THREADS that allows the number of threads created by the task graph to be set directly.
- Add a define that forces the AsyncUploadQueue to use the primary copy queue instead of creating a secondary copy queue.
Signed-off-by: bosnichd <bosnichd@amazon.com>
I actually tried this approach before and it didn't seem to work the way we needed, but I realized that's because PropertyAssetCtrl wasn't handling missing assets properly. I fixed a few issues there including showing the error button when the asset can't be found, and fixing a broken reference to the error icon file.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
* Fix race condition where asset would finish loading and another request would start before the streamer request could be cleared
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
* Re-enable disabled test which was failing for the same reason.
Fix test timeout which was way too long.
Reduce test iterations to keep test time safely under 5 seconds.
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
* Instead of using a mutex, re-order the statements to remove the streamer request first
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
* Adding undo support to SetComponentProperty to make it function with prefab system
Signed-off-by: Mikhail Naumov <mnaumov@amazon.com>
* Renaming a variable
Signed-off-by: Mikhail Naumov <mnaumov@amazon.com>
* PR feedback
Signed-off-by: Mikhail Naumov <mnaumov@amazon.com>
Replaced and removed the CryTimer (gEnv->pTimer). The new TimeSystem is a merger of the current time functionality found in the engine.
* Rename TimeSystemComponent.h/.cpp to TimeSystem.h/.cpp
* Adding New TimeSystem
* remove old timer cvars
* small improvements to the time system.
- updated parts to use the time conversion functions.
- in AdvanceTickDeltaTimes applying t_simulationTickScale is now uses doubles instead of floats.
* Replace gEnv->pTimer / ITimer usages with TimeSystem
* Updating usages of AZ::TimeMs{ 0 } and AZ::TimeUs{ 0 } to AZ::Time::ZeroTimeMs and AZ::Time::ZeroTimeUs
* red code the CryTimer
* using TimeUs instead of TimeMs is some cases + updating usages of old cvars to new
Signed-off-by: amzn-sean <75276488+amzn-sean@users.noreply.github.com>
the owner has removed it!
This fixes the issue by forcing NameDictionary to not transfer
ownership. This means ComponentApplication()::Destroy will fully destroy
the NameDictionary before the OS::Allocator is destroyed.
In Windows the bug was not happening when running AssetProcessorBatch
because for Windows, _exit() is called before the application shutsdown
forcing all module to properly decrease the reference count of
EnvironmentVaqriableHolderBase::m_useCount for NameDictionary.
In MacOS, there's no _exit() so when the NameDictionary destructor was being called
before existing the application the reference count wouldn't be 0, and
would eventually try to destry the NameDictionary BUT the OS::Allocator
was already destroyed.
Signed-off-by: galibzon <66021303+galibzon@users.noreply.github.com>
This change adds a `DomBackend` interface and a `DomBackendRegistry` for backend discovery (currently not hooked up to anything) alongside a JSON backend implementation.
The JSON backend comes with a small suite of unit and performance tests. The unit tests validate generic DOM conversion to and from serialized JSON and rapidjson::Document objects (the support for which lives in `JsonSerializationUtils.h`).
The performance tests show a throughput decrease compared to directly using the rapidjson serializer when mirroring our current pattern of copying strings from the serialized JSON representation, but with the coming in-memory store we have the opportunity to keep the buffer in memory and deserialize in-situ using rapidjson's API, which is consistently at least 100MiB/s faster on my machine (Ryzen Threadripper 3970X). The first parameter is the nested object complexity (N*N, objects with N keys comprised of arrays with N values) and the second parameter is the base size of the strings within each entry of this object.
```
----------------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
----------------------------------------------------------------------------------------------------------------------
DomJsonBenchmark/DomDeserializeToDocumentInPlace/10/5 0.050 ms 0.050 ms 10000 bytes_per_second=355.816M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/10/50 0.057 ms 0.057 ms 11200 bytes_per_second=386.064M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/100/5 4.77 ms 4.88 ms 112 bytes_per_second=364.046M/s
DomJsonBenchmark/DomDeserializeToDocumentInPlace/100/500 11.6 ms 11.7 ms 64 bytes_per_second=554.518M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/10/5 0.084 ms 0.084 ms 7467 bytes_per_second=212.55M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/10/50 0.099 ms 0.100 ms 6400 bytes_per_second=220.608M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/100/5 8.22 ms 8.16 ms 90 bytes_per_second=217.847M/s
DomJsonBenchmark/DomDeserializeToDocumentWithCopies/100/500 23.2 ms 22.9 ms 30 bytes_per_second=283.56M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/10/5 0.070 ms 0.070 ms 11200 bytes_per_second=255.049M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/10/50 0.086 ms 0.087 ms 8960 bytes_per_second=253.258M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/100/5 6.86 ms 6.84 ms 112 bytes_per_second=260.033M/s
DomJsonBenchmark/JsonUtilsDeserializeToDocument/100/500 22.8 ms 22.9 ms 32 bytes_per_second=283.158M/s
```
For `AZ::DOM::Document`, the current plan is to offer helper methods that can load from a file path or string using a given backend that can take advantage of in-place parsing by internally storing the serialized buffer.
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
This change was made years ago in CrySystem (see CSystem::HandleMessage in System.cpp), but looks like it never made it into the NativeWindow_Windows version.
Signed-off-by: bosnichd <bosnichd@amazon.com>
John
AMZN-stankowi
bosnichd
AMZN-Igarri
santorac
Chris Galvan
amzn-mike
Gene Walters
amzn-sj
Mikhail Naumov
SergeyAMZN
amzn-sean
Danilo Aimini
rgba16f
Sergey Pereslavtsev
Guthrie Adams
chcurran
Nicholas Van Sickle
galibzon
Tom Hulton-Harrop
AMZN-AlexOteiza
Esteban Papp
moraaar
lsemp3d
Ronald Koppers