Re: No more font.wait()?

David Crawshaw <[email protected]> writes:
> I remember discussing this new text rendering system, but I'm just
> unsure: is this the end of font.wait()?

Yes

> Can font.width() be safely
> called from the foreground thread? Would be pretty cool if possible.

Yes.  Because asynchronous fonts are just too much of a pain in the
ass, we now assume that glyph rasterization is "fast" where "fast" is
defined as "can be done in the foreground thread without lagging the
UI".

The only consequence is that we need to find a way to make the user
force the font's stream to download before they're allowed to use the
stream as a font (since waiting for the font to download definately
isn't considered "fast").

> Also, I think I've worked out why my selection system doesn't look
> right. Rendering is happening after each Scheduled thread completes,
> isn't it?

Generally, but you shouldn't assume that.

> Back in Lithium days, I believe the core waited for a break in
> background thread activity before rendering. Is it going to be such
> again?

You shouldn't depend on one or the other.  The only guarantee is that
if you change the box tree, the screen will get updated "shortly"
thereafter, for some reasonable definition of "shortly".

> Otherwise, a lot of code is going to be complicated, because all of
> the rendering tasks you want to appear at once need to be complete
> before the current thread is finished processing. Messy.

Okay, you get one additonal assumption -- rendering will only happen when

  1. you return from a thread function
  2. you block
  3. you return from a mouse/keyboard/resize event handler

  - a