No more font.wait()?

[David Crawshaw]

I remember discussing this new text rendering system, but I'm just
unsure: is this the end of font.wait()? Can font.width() be safely
called from the foreground thread? Would be pretty cool if possible.

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?

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?

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.

-- d

[Adam Megacz]

Post by David Crawshaw
I remember discussing this new text rendering system, but I'm just
unsure: is this the end of font.wait()?

Yes

Post by David Crawshaw
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").

Post by David Crawshaw
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.

Post by David Crawshaw
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".

Post by David Crawshaw
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

[David Crawshaw]

Post by Adam Megacz
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

So are these rendering points guaranteed?

My problem was: I had one thread change the position of a cursor, then
instance another thread that created the selected region.

Because the rendering happened twice, you could see the difference
between these events.

It's not a problem now because all this code now runs in the
foreground. But it still might pop up somewhere else.

-- d

[Adam Megacz]

Post by David Crawshaw

Post by Adam Megacz
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

So are these rendering points guaranteed?

No. But there are guaranteed to be no others.

Post by David Crawshaw
My problem was: I had one thread change the position of a cursor, then
instance another thread that created the selected region.

Bad. If you want two things to appear simultaneously, you must do
them in the same thread without doing any blocking-things in-between.

- a

[David Crawshaw]

Post by Adam Megacz

Post by David Crawshaw
My problem was: I had one thread change the position of a cursor, then
instance another thread that created the selected region.

Bad. If you want two things to appear simultaneously, you must do
them in the same thread without doing any blocking-things in-between.

Yep. I've been thinking about it, and I think it was a special case
where trap-based designing fell down because of font.wait().

There's no other situation I can think of where this would pop up
again, so as long as those three points are well documented in the ref,
no worries.

-- d

[Adam Megacz]

Yeah, I file this in the same category as "kernel memory is not swappable".

- a

Post by David Crawshaw

Post by Adam Megacz

Post by David Crawshaw
My problem was: I had one thread change the position of a cursor, then
instance another thread that created the selected region.

Bad. If you want two things to appear simultaneously, you must do
them in the same thread without doing any blocking-things in-between.

Yep. I've been thinking about it, and I think it was a special case
where trap-based designing fell down because of font.wait().
There's no other situation I can think of where this would pop up
again, so as long as those three points are well documented in the
ref, no worries.
-- d
_______________________________________________
core mailing list
http://lists.xwt.org/listinfo/core