Depth component of a TextArea about glyphon HOT 8 CLOSED

Hi! We need to create a proper example here. In general we're just using metadata to pass through something we can use to derive the depth later on.

So you'd set some metadata set on the Attrs for the buffer, then use prepare_with_depth with some function to pull the metadata and get the depth (however you want).

e.g. here's a really simple example where we just pack the depth into metadata directly, but you could do something more complicated if you want to pull depth values from somewhere else (based on a ID, order, etc.):

let attrs = Attrs::new()
    // Pack the depth into metadata directly
    .metadata(depth.to_bits() as usize)

buffer.set_text("I have a depth!", attrs);

// Later when preparing the text area...

renderer.prepare_with_depth(
    /* ... rest of the arguments ... */
    |metadata| {
        // Convert metadata to depth however you'd like
        f32::from_bits(metadata as u32)
    },
);

from glyphon.

Thanks, I overlooked the attributes!

Is the idea that the TextArea and Buffer should be ephemeral? That the prepare statement on the FontRender class can be called once, and then repeatedly rendered until something changes ?

from glyphon.

Yeah exactly. You can call prepare whenever text/attributes change (maybe optimistically if the amount of text is tiny), then re-render as much as you'd like. You could also split into multiple groups of text areas to prepare/render if their frequency is different, e.g., if you have one label that changes at a high frequency but other text is relatively static.

from glyphon.

Cool, got it.

Just one more question.

What was the rationale for having a reference to the Buffer in the TextArea? Instead of Prepare taking for example a Vec<(Buffer,TextArea)> ?

from glyphon.

Buffer and TextArea can have different update frequencies depending on the application, so I wanted to allow reusing buffers while recreating text areas on-demand. e.g., maybe during a resize the text area bounds change so we want to clip to those new bounds, but we might not want to change the buffer in that case. In practice this means you'd probably cache buffers but recreate text areas somewhere near the prepare call.

You can also reuse one Buffer across multiple TextAreas though that's a pretty niche use case.

from glyphon.

Ok, so for example a UI Widget struct that needs some text drawn, should have a Buffer as a member that can later on be referenced by a `TextArea when preparing.

from glyphon.

Yeah exactly, or maybe some buffer cache that's shared between UI widgets depending on the lifecycle of the UI Widget.

from glyphon.

Thanks for your work on this library and answering my questions!

from glyphon.