Added gradient example

[Kwarrtz]

This adds an example using Sprite to the existing PR #627

[Kwarrtz]

I'm also happy to add comments and a screenshot and so on, but I wanted to see if you had any thoughts first.

[dhardy]

Thanks for the example. I'll update my PR. (Looks like Sprite::allocate is unnecessary.)

[Kwarrtz]

Rendering here is unnecessary if the new size matches the existing size. Sprite already caches the existing size; I'll make it available.

Oops, yes, I meant to check that and just forgot.

Rendering shouldn't happen if already in progress (hence why I used a state enum). Kas often calls set_rect twice on start (it's to do with window sizing and maybe / maybe not fixable). Window resizes may happen faster than the re-render speed (can cause lag & high CPU usage).

Never triggering a rerender when one is already in progress could leave the image out of sync with the size of the Sprite. E.g., if we call set_rect(rect1) and then, before the render is complete, set_rect(rect2), the buffer will be stuck with size rect1 (until a new call to set_rect). I think my current implementation avoids both this and unnecessary rerenders, but are superfluous calls to set_rect really common enough to make this worth it?

Also, to fully optimize this, we would want some way to cancel in progress rendering when a resize makes it obsolete. Should send_spawn return some kind of task handle to allow that?

It doesn't verify the image size matches the allocation. I'll fix this.

Why does this require us to pass the size into image_upload? Shouldn't we just check data.len() against image_size(handle)?

[dhardy]

The size test is less important now (image_upload will fail if it doesn't match the allocation).

But what isn't handled here is the case rendering was already in progress when set_rect was last called, and thus size != self.sprite.rect().size, so that needs handling (optionally upload this result anyway).

[Kwarrtz]

We still need to re-allocate if the size of the image has changed. Removing that check won't cause a panic but it will cause the upload to repeatedly fail and so the image won't update.

[dhardy]

You're comparing the size used by the render buffer to the allocation. There's a third size: sprite.rect().size.

[dhardy]

Never triggering a rerender when one is already in progress could leave the image out of sync with the size of the Sprite.

Svg and Canvas handle this by checking size again when receiving a render result.

but are superfluous calls to set_rect really common enough to make this worth it?

At least on my system (Wayland/Linux) resize events can happen rather quickly. When it works right, resizing the window feels very responsive, but it can also cause excessive load.

Also, to fully optimize this, we would want some way to cancel in progress rendering when a resize makes it obsolete. Should send_spawn return some kind of task handle to allow that?

I don't think this matters. Even if the result is outdated, it's probably more accurate than the previous one, so e.g. Svg will upload anyway.

Hmm, futures can be "cancelled" by just dropping them (though "cancel safety" depends on the futures). I haven't provided any way of doing that; not sure if I should to be honest. It's still possible for long-running tasks to use shared state to check whether they should terminate themselves.

[dhardy]

Why does this require us to pass the size into image_upload? Shouldn't we just check data.len() against image_size(handle)?

Theoretically size.0 * size.1 could still match data.len() while being wrong, but this is besides the most important point: data.len() must match. This is currently only checked with an assert.

So go ahead and remove the size parameter if you like and replace the assert_eq on data.len with something like return Err(UploadError::DataLen).

[dhardy]

You'll also need to check --features soft since there are two rendering backends.

[Kwarrtz]

Converted to draft because I need to spend a bit more time looking at the soft backend to figure out how best to integrate with its existing error-handling scheme. I don't think the previous commit is the best choice.

[dhardy]

These tex uploads (from text glyph rastering) shouldn't fail, but in case they do this shouldn't stop the remaining uploads. Possibly best to catch-and-ignore here with a note about the cause having been logged.

[dhardy]

@Kwarrtz would you like to rebase your example? The changes to Kas crates are no longer needed.

[Kwarrtz]

Done. The example itself is pretty much unchanged from before, just had to move the image format argument from upload to allocate. Seems to work fine on both backends.

[dhardy]

LGTM thank you.