[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: new rendering stuff
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       1999-12-13 11:58:02
[Download RAW message or body]

On Mon, 13 Dec 1999, Antti Koivisto wrote:

> Lets try the mailing list... CVS is bit crappy as a discussion forum. :)

But nice for writing down the results ;)

> <me>
> > Some thoughts about khtml's new arcitecture:
> > 
> > Old HTML*Impl classes will be split so that all layouting and
> > rendering methods (layout(), updateSize(), calcMinMaxWidth(),
> > setAvailableWidth(),  print(), printObject()...) will be moved to
> > new rendering classes. There will be a  rendering class for each
> > value of css2 'display' attribute. Some others (#text, replaced
> > elements...) will also get their own rendering classes.
> >
> > All attribute values used for layouting and rendering are kept in
> > the style objects. Style objects are implemented as copy-on-write
> > objects. The values are shared with the styles parent style as long
> > as no values are changed. The values are divided to groups 
> > ( box, text, border, table...) and only when a value within a group is 
> > changed, that groups data object is copied.
> 
> ><lars>
> >We have to do an additional division here. Some properties are inherited, 
> >some others aren't. So we only have to copy the values, which get 
> >inherited from the parent. Others will get set, if a style sheet
> >defines a value for it, otherwise one should use the default values.
> >For example the background color/image isn't inherited, so the style
> >derived from the parent elements style shouldn't have it set. We should 
> >only have inherited values in the "copy on write" classes, since we
> >might run into trouble otherwise.
> ></lars>
> 
> Background color is not inherited, but it is cascaded. After
> P { background-color: red } all P elements have red background, whether
> or not they have align=left or right. It certainly makes sense to
> have only one copy of bg attributes for all P elements in the document.

Yes, but you should remember, that the main mechanism for setting values
is inheritance. About half of the CSS properties are inherited. 
And setting of properties is done in the order:
1. if(inherited) set to parents value
2. go through the cascade
3. set values implied by attributes 

In my oppinion, we should not mix between inherited values and non
inherited ones in a group (like StyleBox).

> Style objects are not meant to be the same thing as style sheets. They are
> simply data objects for the rendering system and are constructed and filled
> by other objects. It might make sense, to have copy operation based on css
> inheritance rules in addition to simple copy constructor, for convenience.

As I said, the first step in the construction of a style object has to be
by inheritance rules. So we need a constructor (or a method), which just
constructs a new style object derived by inhertance rules from the parent
object. Only after that, we can apply the cascade (since explicit
setttings in the cascade have to overwrite inherited settings).

> Style objects, however, are not responsible for enforcing the inheritance
> and cascading rules. That job belongs to CSS objects.

No they aren't. But the creation mechanism has to obey it. And as I said,
we should split up the style objects in a way, that makes memory
consumption minimal. If a style object mixes inherited and not inherited
properties, you will have one write operation for sure (either, because
you have to change something due to inheritance, or because of cascading).

> ><lars>
> > One big problem we have is, that usually (in almost all cases), only
> > computed values are inherited, not the defined ones.
> >
> > So if e.g. an indent is set to 2.5em, then one has to convert the
> > 2.5em to pixels, and only the pixel value is inherited.
> > 
> > For some properties the calculation is trivial and can be done directly.
> > In this case, the values in style.h can be absolute pixel values instead 
> > of Length type values. For some others, like margins, the calculation might
> > be more complex, and might have to be done at layouting time. Then
> > Length type values are more appropiate.
> > </lars>
> 
> The rendering subsystem operates only with pixel and 
> percentage values (otherwise big changes are required). Everything 
> else is converted to this form before the style object is constructed. 
> The conversion should probably be done by CSS2 classes that make
> the style objects.

Agreed. I will try to convert as much as possible to absolute values,
before settting it in the style object. There are a few things were this
might not be possible (I can mainly think of margins and borders at the
moment, but there might be some more). These values can be converted to
percentage values relative to the parents width/height.

> >> The base parent style is defined by the documents style sheet, or
> >> document types default style sheet. This style is then used as a
> >> base for element specific styles and these are futher modified by
> >> local style definitions, element attributes or by  scripts. 
> 
> > <lars>
> > I will provide a method, which returns the style object to use given
> > the parents style object, and the sum of all style sheets. So the 
> > renderer/parser will just have to do a  CSSObject->getStyle(this)
> > to receive the correct style object. This is IMO the cleaner
> > solution, and it's also more flexible, since the Selector used 
> > in the style sheet might be something weird ( table.special td[bgcolor=red] 
> > for example). So the style object might have to look up parent elements and
> > attributes, to be able to decide if a certain rule applies to the element
> > or not.
> > /lars>
> 
> Yep, this is ok. I was not trying to explain the implementation, only
> what should generally happen. I was thinking that this could be somehow
> analogous to the old rendering system; instead of painter, CSS2 tree 
> "renders" itself to a style object. The element type/classes act as
> coordinates. (i might be reeeeally far off...:)

Not sure I understand that. We will always need a painter to
render the object to a QWidget (or better: a QPaintdevice).

Lars

> >> Every rendered DOM object has a pointer to a rendering object.  When
> >> a HTML DOM  object is added to the document tree, it gets a style
> >> object that matches its class,  parses its attributes and modifies
> >> the style object accordingly. Then it sends the style object to its
> >> parent elements rendering object. The rendering object reads the
> >> value of 'display' and constructs and adds a suitable child
> >> rendering object(s).  The pointer to created rendering object is
> >> returned to the HTML DOM element, and is stored.
> >>
> >> All data needed to layout an element is kept in the style objects.
> >>
> >> The layouting and rendering in the rendering tree works pretty much
> >> as it used to with *Impl objects. In the beginning of layout()
> >> frequently accessed attribute values  may be fetched and temporaliry
> >> stored to the rendering object. In the end the possible calculated
> >> attribute values are stored back to the style object.
> 
> ><lars>
> >Don't think we will need that. Attribute values are never modified by
> >the layouting process. What gets calculated is the actual geometry
> >of the element. I would store this information in the rendering object.
> ></lars>
> 
> You are probably right about this
> 
> >> Scripting and event are done in the DOM (not rendering) tree. The
> >> DOM objects may for example ask element position from their
> >> rendering objects to invoke  mouse events. Modification to element
> >> attributes by a script are done by modifying the elements style
> >> object. Similary, the attribute values can be read from the  style
> >> object. However if value of elements 'display' attribute is changed,
> >> the rendering tree must be at least partially reconstructed.
> >
> > <lars>
> > The attribute values need to be stored in the DOM only. We'd be
> > asking for trouble if we started storing them in the style objects.
> > Attributes are not inherited, just the influence they might have
> > on rendering is. So the way to do this is to store them in the DOM, 
> > and everytime an attribute gets modified, it'll look if it has to modify
> > style object, and if yes, force a relayouting.
> > </lars>
> 
> Yes, you are right here. The modification should be done to DOM object 
> and then reflected to the style object if needed.
> 
> 
>   ak
>  
> 
> 

-- 
Lars Knoll                                 knoll@mpi-hd.mpg.de
  PGP pub key [6DADF3D5]: finger knoll@pluto.mpi-hd.mpg.de 

[prev in list] [next in list] [prev in thread] [next in thread]