[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] Re: [zzdev] Changing back others' changes



You wrote:
> Apologies. I was in a hurry - a screenshot was due in half an hour and
> the code was rendering very screwily. I was basically going AAARGGHH and
> flying from file to file ;)

And I was just waking up and didn't feel very good. Sorry for having been
grumpy :o)

> > In the case of SceneFlobs, note that boxed flobs have a needsBox()
> > method. You can override it to return false.
> 
> Ah, right. The problem there is that I haven't really touched the old
> code in a while so I didn't know this. I just committed the code to
> do it your way.
> 
> Hmm... the name is a bit odd: I'm not saying that a RotatedSceneFlob
> doesn't need a box, I'm saying that it *mustn't* be boxed...

Hm, the original logic was "normally we don't render boxes at all; we only
do if a flob NEEDS 
them." Note that needsBox is in Flob, not BoxedFlob, for a reason I don't
readily remember. So here 
we assume that normal flobs don't need a box.

> > In the case of FTextLayouter, why not add a structparam (which can be
> > set through the constructor, see firstCap) which decides whether to clip
> > or not? i.e. doClip or some such.
> 
> Sure. OTOH, the single text strings should never be clipped - that's 
> woefully inefficient. Instead, the code using the ftext should place e.g.
> a sceneflob outside which would do the clipping. Not committing a change
> yet.

Remember that for an average VanishingView with a linebreaking cell view,
that means some hundred 
flobsets because a sceneflob contains a flobset. *That's* woefully
inefficient. (An earler version 
of FTextCellView did that and I changed it because it was too slow.)

Also note that the code *only* clips if a line is too long for the box. The
hope is that usually 
they will not be, at least in long blocks of text (which is where the
sceneflob would be an 
efficient alternative).

-b.

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Attachment: "
Description: Binary data