use handleid in renderer instead of a weak handle

[mockersf]

• The renderer only need a weak handle, so it can work with the HandleId
• Tiny perf improvement
• This was already done for the sprites

next question would be to replace the type uuid by a smaller unique id: uuid is backed by a u128, but a u64 would be largely enough to have a unique id for asset types, and make the HandleId enum the same size for both variants

[alice-i-cecile]

next question would be to replace the type uuid by a smaller unique id: uuid is backed by a u128, but a u64 would be largely enough to have a unique id for asset types, and make the HandleId enum the same size for both variants

Yes, I think this is reasonable. We can only have u64::MAX entities anyways.

[mockersf]

Moved the uuid to a u64 internally, but still kept the same api where you need to provide a Uuid on the derive because it's prettier... and I didn't want to change the derive macro without other opinions.

This wins around 3 fps on many_sprites and many_cubes...

[alice-i-cecile]

This wins around 3 fps on many_sprites and many_cubes...

Wow, that's way more than I expected.

[superdump]

Moved the uuid to a u64 internally, but still kept the same api where you need to provide a Uuid on the derive because it's prettier... and I didn't want to change the derive macro without other opinions.

This wins around 3 fps on many_sprites and many_cubes...

3fps out of how many? :) Cool!

[mockersf]

	many_cubes	many_sprites
before	80~84	67~68
after	84~86	68~70

[superdump]

In some places in the code, functions and such are still called 'uuid' which feels incorrect as uuid is something specific and this is not a uuid anymore.

Also, I haven't thought about the consequences and I'm imagining that @cart has. :)

[mockersf]

In some places in the code, functions and such are still called 'uuid' which feels incorrect as uuid is something specific and this is not a uuid anymore.

Also, I haven't thought about the consequences and I'm imagining that @cart has. :)

Yup, before taking the step to yank all references and use of uuid, I was waiting for someone who may have ideas about unexpected consequences...

and then, for the derive, having a uuid does look nicer than having a random u64...

[bjorn3]

I think the asset type should keep using an uuid. A u64 is not enough to be almost certain that the type id's chosen by different plugins are globally unique across all plugins. If this is not the case, trying to use plugins with conflicting type id's will cause surprising and incorrect results that may be hard to debug.

[mockersf]

trying to use plugins with conflicting type id's will cause surprising and incorrect results that may be hard to debug.

Nop, it panics. there is a check when adding a new asset type that panics if its ID is already registered, and the message should be explicit enough

[bjorn3]

That will still prevent the plugins from being used at the same time.

[mockersf]

Neither uuid or u64 are a perfect solution to prevent collisions... and people will copy paste existing values from sample code
Until we have an plugin catalogue capable of warning of collisions, I'm not sure that will be a solved issue

[cart]

Some assorted thoughts:

• I like the idea of trying to reduce the runtime cost of handles.
• I would like to retain type safety on the renderer side. Weak handles should be "cheap enough" to use in this context. If they aren't (clearly there is currently a cost here), thats something worth resolving.
• Uuid should always only mean "actual uuid". TypeUuid should continue being a real Uuid. It is the standard way to avoid collisions in a distributed context.
• Its worth considering "exchanging" a UUID for a "runtime atomically incrementing id" for assets, which could be much smaller.
• In the very near future I'll be picking up the "asset preprocessing" area. Some or all of this code might change as a result.
• bevy_reflect owning something like UniqueAssetId feels wrong.
• I'd like to explore treating assets as entities. In that world, we'd be using entity ids (potentially inside a typed handle) in place of HandleIds.

[alice-i-cecile]

In that world, we'd be using entity ids (potentially inside a typed handle)

For context / cross-linking, this is the kinded entities idea from #1634.