Split of referrence batches into Core/non-Core

[kvark]

(This is a breaking change, please review carefully)

I noticed a couple of things that weren't sound:

1. RefBatch carried a publicly accessible slice, while not carrying the parameters. The reason for the former was "convenience" (IIRC), the reason for the latter was "just because we can". Hence, this type was neither complete nor minimal.
2. A lot of applications tend to keep a parameter structure together with a RefBatch. They are often seen together, and that wasn't convenient to do.

As a solution, I made a RefCore batch that only carries minimal (for safety) sealed data, nothing is available to public. The RefBatch now is rather open - it carries the core as well as a slice (like it used to) and a parameter structure, all mutable by public.

The idea is - RefCore to be used for maximum flexibility, like creating a batch when not yet having a parameter structure at hands, or using it with multiple parameters/slices. While RefBatch is just a convenient thing to have. The maintenance cost is minimal, since they are re-using lots of code.

RefBatch is also nice for ergonomic reasons - you can create a batch with type inference.

[bvssvni]

Looks good.

[brendanzab]

Good stuff. Maybe impl on an enum TestResources {}?

[kvark]

Agreed

[brendanzab]

Does this need to be in this PR?

[kvark]

This allows make_batch, make_core, and bind to be called from Graphics, instead of wrapping them up into pass-through methods.

[brendanzab]

Hmm, ok - just think it might be an abuse of Deref, which is a debate I would rather not have on this PR.

[kvark]

Feel free to open this debate anywhere please. I'm not too experienced with Deref practices and would be happy to know more.

[brendanzab]

Referenced

[kvark]

will fix

[brendanzab]

What other names have you thought of? What about RefBatchData?

[kvark]

I haven't really thought about names, no. RefBatchData doesn't sound too good because it bears the "data" term, while in fact RefCore can be seen as a batch type. Yes it is incomplete (requires not only the context, but also a slice and a parameter data), but neither is RefBatch (needs the context).

I don't insist on RefCore name though. My understanding is that since we don't re-export everything in batch module, this type is accessed as gfx::batch::RefCore, which makes it less ambiguous. Perhaps, you'd prefer CoreBatch more?

[brendanzab]

We can iterate on naming later, I think.

[kvark]

One of the reasons behind the PR is also an attempt to standardize handle operations. I don't like the fact that some handles are copyable (BufferHandle) and others are only clonable (ProgramHandle). I think we should be consistent with this, and Clone is the common denominator. That's why Slice is no longer copyable, for instance.

[kvark]

@stjahns this PR would improve this code in skeletal_animation:

pub struct SkinnedRenderer {
    animation_clip: AnimationClip,
    skinning_transforms_buffer: BufferHandle<GlResources, [[f32; 4]; 4]>,
    shader_params: SkinnedShaderParams<GlResources>,
    batch: RefBatch<SkinnedShaderParams<GlResources>>,
}

Also, I believe you really need this to be device-agnostic:

pub struct SkinnedRenderer<R: Resources> {
    animation_clip: AnimationClip,
    skinning_transforms_buffer: BufferHandle<R, [[f32; 4]; 4]>,
    batch: RefBatch<SkinnedShaderParams<R>>,
}

[stjahns]

Works for me / Am I doin' it rite?

[kvark]

Self-merging as everything is fixed and the concept has been approved.