Re: [Fresco-devel] Getting the basics straight, was: Text styles/cloning graphics

Tobias Hunger wrote:

>>what has 'the situation of the TextBuffer' to do with linebreaking and
>>layout ?
> 
> 
> s/situation/contents/ Sorry, bad english.

well, the question remains. Layout is a presentational issue, and has
nothing to do with the textbuffer content. (forced breaks are a
different matter, of course).

>>I'm all for good and fine-tuned caching where appropriate, but the
>>correctness of the server's behavior mustn't depend on it. Read: caching
>>is an implementation detail.
> 
> 
> Agreed.
> /me wonders where that 'no' came from if we are agreeing;-)

because you wanted to mandate caching, i.e. include it into the
semantics of the objects.

> OK, so we do agree about there should be some form of caching? That's where I 
> started from too: I fealt it is natural to use Graphics to cache the actual 
> layout: Describing basic elements, their size and position is what they were 
> designed for. Do we still agree?

not sure. Caching positional information is good. We do that already.
What do you mean with 'use graphics to cache the actual layout' ? 
Graphics are part of the scene graph, which is rendered. In the 
rendering we compute a lot of things such as the graphics' 'external 
state' (Flyweight !), which thus is a good candidate to be cached, 
especially if the computation is non-trivial such as in text processing.
But the graphics themselfs are agnostic of that.

> If we do want to use Graphics for that caching we will need to arrange them in 
> a way that reflects the linebreaking, the styling of the glyphs, etc. To do 

that's where I disagree. As I said, the scene graph is one thing, 
rendering it another. The scene graph doesn't care about line breaking 
(as little as it cares about layout issues in general). Only individual
graphics care about what *they* cache. But that's always local data
only, i.e. a graphic can cache how it layed out its children last time
it was traversed. It mustn't manipulate the scene while doing this.

> that we will need to find a way to apply decorators across linebreaks, which 
> results in the need to duplicate decorators: A clone() method. Agreeing?

nope.

> Such a method might proof to be useful in other contexts too.*Still* agreeing? 

dunno, and I don't care as long as I don't see a concrete need.

Regards,
		Stefan