* Removed ununeeded includes from EBus EBus.h and Policies.h
Updated the locations which needed those includes
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Adding missing include for <memory> to AWsClientAuthBus.h
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Remove the while true loop in the EBusQueuePolicy Execute() function
The while true loop in Execute was for allowing additional functions to be queued in the middle of execution of current list of functions.
That functionality was dangerous, because if a queued function added itself during execution unconditionally, then it would result in an infinite loop
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Updated the AssetManager::DispatchEvents function to pump the AssetBus event queue until empty
Queued Events on the AssetBus is able to queue additional events on that Bus during execution of those events.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Changed the AssetManager::DispatchEvents function to only execute the
AssetBus queued events once
Changed the AssetJobsFloodTest.AssetWithNoLoadReference_LoadDependencies_BehaviorObeyed test to dispatch events until the OnAssetContainerReady callback is signaled.
This happens after every asset load to make sure that the
expiring AssetContainer instances are removed from `AssetManager::m_ownedAssetContainer` container before retrying to load the same asset.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added a MaxTimeoutSeconds constant for the maximum amount of the time to run a single DispatchEvents loop
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Release build fix for Windows
* Release build fix for Android
* Release build fix for Windows
* Release build fix for Android
* Release build fix for Linux
* Release build fix for Mac
* Release build fix for iOS
Signed-off-by: Steve Pham <spham@amazon.com>
NOTE: The memory driller is still intact for now to avoid needing to
modify allocators, but the frame/cpu portions of driller and the
standalone executable are now gone.
Signed-off-by: Jeremy Ong <jcong@amazon.com>
* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>
* Fix recursive attempts to open the log file in the GameLauncher
The AzFramework Application has been updated to default the @user@ and
@log@ aliases to the <engine-root>/user and <engine-root>/user/log
folder respectively if a project isn't set.
Fixed the SystemFile class to support negative offsets if Seek() as per
standard seek function such as fseek
Updated the CrySystem CLog class to use SystemFile instead of FileIOBase
to avoid any asserts that would cause CLog::OpenFile to be recursively
called infinitely
* Removing unused Force Closed variable
* AZ::IO::SystemFile build fixes for Unix platforms. Added a copy constructor for LUAEditorContextInterface.h to fix the LuaEditor build
* Adding missing includes to the WindowsAPI and Android SystemFile headers
TLDR
Thumbnails size will be removed from the system.
Each thumbnail class is responsible for determining its stored size.
Images and other thumbnail types can be scaled up or down within reason without blurring.
The thumbnail system uses the concept of context and size organize thumbnails by size based on their intended use. However, most of the thumbnail classes do not respect or use the specified size, which is 16 by 16 pixels and really only usable for small icons.
The thumbnails are currently being used in the asset browser tree control, the larger asset browser previews, the material component property asset controls, the material component inspector for the large preview, and other places. Each of these places use completely different sizes, some of which are large and change dynamically. Whenever the thumbnails are painted they are scaled to the desired size.
Material and mesh thumbnails were always being captured at 512x512 regardless of what the rest of the thumbnail system said. Source, product, and folder thumbnails would be stored at the original asset size. The loading movie thumbnail was always drawn at 16 by 16 and scale up so it was always blurry. Image thumbnails were always scaled down to 16 by 16 and scale up for larger previews.
Rather than worrying about the size of each context, each thumbnail class will store the image at whenever it deems to be a large enough size that can be scaled down when used.
This may eliminate the need for multiple thumbnail contexts which are not being used anyway.
https://jira.agscollab.com/browse/ATOM-15370
FiniteStateGit
Esteban Papp
lumberyard-employee-dm
Steve Pham
Jeremy Ong
Terry Michaels
bosnichd
mbalfour
guthadam
Chris Burel
alexpete