
Things we discussed (in no particular order):

- massive improvements to dynamic changes propagation (setChanged, 
  applyChanges and friends). Lars is currently working out the details. 
  outline: 
    - dom nodes will only be setChanged(true), when they get new
      CSS attributes applied (addCSSProperty in parseAttribute i.e.) and
      in to be defined (rare) other cases. 
    - changed nodes will calculate a new RenderStyle. when the 
      set of the _inherited_ CSS attributes changed in the renderstyle,
      we have to recalculate the style for all subnodes and apply it.
      otherwise, only the changed node will get a new style.
    - Render*::setStyle will check if the stylechange invalidates the
      layout or not (i.e. group into relayouting-changes and repainting-
      changes depending on the CSS property). it will trigger the
      necessary action then. 

   possible: post relayout / repaint events in a queue and add
   event compression to reduce amount of single relayouts/repaints
   and avoiding excessive updates.

   needs lots of testing, expecting regressions.
   expecting massive performance improvement (factor 20-30)
   for the usual Javascript effects, which only move / show / hide 
   positioned elements and do not invalidate inflow layout. 

- implementing a khtmlFont class that will implement the missing CSS1
  support and work around the "entity is not in font -> replace it with string"
  problem (i.e. &tm; -> "[TM]" instead of single char if font doesn't support it)
 
  class will cache a "visual" representation of the string with the changes:
    - lower / uppercase string according to CSS attribute 
    - unknown chars replaced 
    - a fontmetrics cache until Qt finally implements it. 
  
  class will implement the missing letter spacing / word spacing / justify
  by using a modified painting routine for them. 

  straightforward, regressions not expected. planned to be done for 3.0
  in possible hacky way to gain CSS1 compliance, other things possibly
  later. 

  possible: further integrate this into rendertext, possibly making
  textslaves allocation more dynamic. The agreement was that this
  is very difficult and the gain is not expected to be big -> 
  low priority.

- an "element" pointer in all Render* objects. moving of the "in node"
  and "innermost node / over url" determination code to the rendertree,
  to be able to fix the visual z-order problem and the massive slowdown
  due to the extraordinarily stupid current implementation on big pages.
  Will also reduce the the code overhead significantly. (currently 
  massive code duplication in the dom tree that can be cut out when doing
  things clever).

  disadvantage: none known
  advantage: no renderobject size overhead if done cleverly:
      - some have already an element pointer anyway
      - the renderstyle is already maintained in the dom node
        -> the RenderStyle* pointer in RenderObject is redundant now.
      - RenderStyle does not need the virtual method table pointer -> 
        saving 4 bytes here as well. 
      - every of the planned repaint optimisations will automatically 
        improve the overElement performance as well if done cleverly
        (getting rid of the current code duplications).

  needs some work for the edge cases, needs testing. possibly regressions.
  will be lots of fun for image maps. 

  possible: a "hit cache" to avoid a rendertree traversal upon every
  mousemove-event, and limit it only to cases when it crosses the border
  of the innermost node outline. possible factor 10-20 improvement.
  difficult (impossible) to maintain over relayouts -> invalidation
  possibly. not very high priority. 

- rendertable/htmltableimpl cleanups. This is the biggest and the
  most urgent of the pending jobs. 
   - finally get rid of the "setLayouted(false)" hacks in many wrong
     places in the code and fix the regressions in a sane way. 
   - adding / removing a table cell should never invalidate the layout,
     unless the colinfo structure changes in a way it makes a relayout
     necessary. (this is only rarely needed if the colinfo is maybe
     slightly changed). will fix the O(n^2) behaviour which currenty
     is the biggest slowdown for khtml
   - remove all the hacks that were added from various people
     to fix one or the other rare problem (mostly layout invalidation
     and complete repaint related). collect testcases, think about
     the right way to fix the regressions.
   - fix the painting routines to not iterate over all cells  
     i.e. change the O(n) to O(log n) by binary-searching the right cell
     to print.
   - rework the progressive update behaviour of table cells. do not
     distribute extra width over cells as long as the table is not
     yet completely loaded (assume that most pages set good 
     colum width hints). wait for the first 2 rows of the table to be
     received until starting to distribute width. (one row for the initial
     colinfo allocation, row 2 for the usual colinfo - overwriting 
     many pages use to overcome netscape brokenness). 
   - try to avoid the massive relayouts of tablecells during loading
     the table. the IE way is considered to be better than netscape
     (wait till everything is there), however exact functioning is 
     not yet known. we couldn't agree on good heuristics, needs
     investigation.
   - try to clean up the code, think about reducing the massive
     memory overhead of rendertable. 

   expecting many regressions. needs discipline and much time
   for testing. However we think its urgent enough for 3.0. 

- renderlists should not use floats for inset markers. use
  display: run-in or compact instead. 
  
  easy to do. possible performance improvement for pages with
  long lists. no regressions expected. 

- fix the CSS parsing for content - insertion. either work out
  counter() insertion or make sure we zap it and don't print
  it as raw text. ignore it on listitems (some braindead pages
  use li:before counter(foo bar) for defining the listitem style). 

- paint buffer optimisations. always paint full paint buffer height,
  cache the currently unneeded parts for possible later paint events.
  disable paintevent clipmasks in scrollview as we always paint  
  rectangular areas. make sure the repaint event compression is 
  not lost.

  low priority, but easy to do. 

- clean up the mess in xml/. reduce the massive code duplication.
  ban domstring comparisions in all performance critical parts
  of the impl classes, which got added for some reason (?). 
  use an id-sheme which cleverly encodes namespace and localname
  for full DOM2 compliance in an 32bit integer for elements and
  attributes. remove all the current crap. 

  - share the domstring's of non-html element names / attribute names
  to reduce memory overhead.

  - do not store a set of AttrImpl*s for attributes to reduce memory
  overhead. use a 32bit id (namespace support) prefix and value 
  pointer in an array and share these structs with on-demand allocated
  AttrImpl's (for the DOM / ECMA bindings. remove them from the
  implementations). Gain is roughly 26 bytes per attribute + saved
  memory for the shared strings. will as a side-effect greatly simplify
  the current code and therefore expected to improve performance.
  (currently htmlcollection and nodelists spend 90% of total cpu
   time in domstring comparisons for heavy Javascript sites).

  possible instability, regressions. Dirk started working on it.

- implement progressive loading in the xml tokenizer (Qt supports
  it now). try to merge some of the html parser / xml parser code,
  which is currently fully duplicated. 

- stabilize the XML support. possibly parse strict and namespaced
  xhtml documents with the xml parser and not the html one for
  improved compatibility and as a testbed for keeping the xml 
  code parts stable (IE 6 also parses with a nonvalidating xml parser)

- adding an "extra" pointer to renderflow. possible with several overloaded
   meanings for extra structs on demand: 

    - elements iwth overflow: scroll will be able to store 2 qscrollbar
      implementations as well as the needed extra variables for 
      correct support

    - flows with complex border / inline css attributes will be able to
      cache often-calculated pixelsize representations in such a struct
      (like contentwidth / height). 
   
   - possibly a jump table for faster searching in long child node lists

  overflow: scroll should go into 3.0. the rest can wait. when doing the
  above memory optimisations, the overhead for this one is neglectible. 

- review the bindings to be compatible to the newly released DOM2
  specs and their extensions. change and add stubs as necessary
  for later BC extensions.

  no regressions, easy but boring work. needs patience. 

- rethink the khtmlpart / plugin API. possibly see if we can work
  out a common plugin interface with opera / mozilla guys. 

  nobody volunteered for this, although it is agreed to have
  high priority. 
   
- doing the still pending form fixes. Dirk's work. 
   
- minor things i forgot...


More things (pmk):

- Make sure all elements update properly when parsing attributes, basically
  what is done in most of the init() methods. This also needs to take into
  account what happens when you insert/remvoe elements, e.g. removing a title
  element should clear the document's title, and then creating a new title
  element again and changing the text should only update the doc's title when
  it actually gets put in the tree.
