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

List:       kde-commits
Subject:    Re: new_rendering: kdelibs/khtml/rendering
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       2000-03-01 8:53:48
[Download RAW message or body]

On Tue, 29 Feb 2000, David Faure wrote:

> On Wed, Mar 01, 2000 at 12:22:52AM +0100, Lars Knoll wrote:
> > On Tue, 29 Feb 2000, David Faure wrote:
> > 
> > > On Tue, Feb 29, 2000 at 06:13:13PM +0100, CVS by knoll wrote:
> > > > 
> > > > kdelibs/khtml/rendering bidi.cpp,1.1.2.30,1.1.2.31 render_table.cpp,1.1.2.22,1.1.2.23
> > > > Author: knoll
> > > > CVSROOT: /home/kde
> > > > Tue Feb 29 18:18:28 MET 2000
> > > > Update of /home/kde/kdelibs/khtml/rendering
> > > > In directory zeus:/tmp/cvs-serv27644/rendering
> > > > 
> > > > Modified Files:
> > > >       Tag: new_rendering
> > > > 	bidi.cpp render_table.cpp 
> > > > Log Message:
> > > > just tried how fast khtml can get if you remove the debug output...
> > > 
> > > If you used kdDebug, all you would have to do would
> > > be to use kdebugdialog or -DNDEBUG :-)
> > 
> > I know. But somehow, we kept sticking to printf's and #ifdefs around for
> > historical reasons.
> :)
> 
> > Anyway, I sometimes need something to work with
> > ifdefs. Try defining BOX_DEBUG in rendering/render_flow.cpp and look at
> > khtmls rendering. No way, you could get an effect like that with kdebug
> > ;-)
> 
> Why ? What's the difference with debug areas (except perhaps speed) ?

No. It does something completely different. It draws a border around every
element. That's usually the fastest way to find out where layouting errors
come from.

> With kdebugdialog you can very easily enable/disable an area...

hmmm... I think khtml would need about 10 areas. And in many places
performace is very critical, so for these, using printf's inside an ifdef
is probably the best solution, otherwise khtml would be slow as long as
you don't compile with -DNDEBUG.

Cheers,
Lars

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