World: r3wp

red text as the characters being red? that is handled by the rich 
text dialect.

if you mean background - then i think so, you have a bg gob and a 
text gob inside or over it.

but i don't know all the details (yet).

ah ... what is text then? or even better - what is following gob 
good for? gob: make gob! [color: red]

it is just color, but color of what?

background.

ie. a colored box

sounds scary ... as ZX spectrum, which could have only 1 color for 
particular bog pen, and one color as a background, where that gob 
was 8x8 pixels :-)

how can be such thing useful? You usually will need either - further 
draw help, or effect (gradient, well, which can be done by draw too 
;-) help .... for simple things, yes ....

but maybe it makes sense, dunno ...

this is done for speed and saving memory

ie it's faster and uses much less memory this way.

functionality-wise it's the same - just use n gobs instead of 1 face 
(could also be 1 gob with draw etc.)

I thought that usually you want simple thing as color be directly 
the part of each gob ... maybe it is more practical? But I would 
have to see how I do simple thing as view layout [text red "ahoy"]

is all text rendering part of rich-text now?

you do that as view layout [text red "ahoy"] :P

why would you need a color for an image?

why would you need a color for an effect?

well, of course, you are right ... but how do I do color of text? 
via rich-text dialect?

yes probably

gob/color is the background color, it would not be the text color 
anyway.

text color is done via rich text dialect afaik.

i guess, that if text is a string, there must be a font specification 
somewhere, with text color in it.

you say rich-text... so a page with a lot of rich text consists of 
one gob, not many?

one gob, exactly.

(one per paragraph maybe. we'll see.)

ok, I just thought that editing text might be heavier, if it didn't 
consist of several gobs.

as I understand it, you can have whole UI in one gob - if your UI 
will be done as one draw dialect block. probably not the fastest 
way anyway :)

correct.

so, can gobs be instanced? like many faces that share the same font 
object

what I don't like (but the design is still not finished so this may 
change) is that there is separate draw and effect block. I think 
R2 way (draw in effect) is much more flexible. Probably merging those 
two dialect would be best.

rebolek, most of the times you are not using both. and using layered 
gobs is going to be faster, probably.

Gabriele, you should check code of some of my demos if you think 
I'm not using both ;) But if layering is faster then OK

i expect layering to be faster, because if you change one layer, 
it is not always necessary to recompute the other layers.

but... you guys need to ask these questions to cyphre :)

henrik: current docs do not talk about anything that could be shared, 
except the effect/draw/text blocks themselves.

that is, there is no font subobject.

i assume font object is referenced from the text block, so if you 
reference the same from many text blocks you are sharing it.

gabriele, ok, bad example. I was thinking more like for a star field, 
you could use one gob, referenced many times.

they would all have the same offset and size then :)

ok, so you reference one image in many gobs?

so, you'd have many gobs, maybe referring to the same effect or draw 
block.

or image - yes.

yep, ok

on gob:

Carl: "Ask if they remember what great graphics system used "boogers 
and goobers".  ;)"

Carl: "If we had to pick worldwide perfect names, we'd have very 
few to pick from.


Also, when you define a word, it is context dependent. It very rapidly 
takes on its new meaning and loses the out-of-context meaning.


Also, if they can create a better 3-letter name that starts with 
G -- then I am open to hearing it.  But, it must happen very soon."

goo :-)

:)

i'll wait a day or so then collect proposals and send them to Carl. 
don't keep your hopes to high though ;)