Skip navigation.
KDE Developer's Journals
Home » blogs » wildfox's blog

It's a long way to Rome.

wildfox's picture
Submitted by wildfox on Wed, 05/18/2005 - 18:38.

The last weeks have been amazing, this is the only word I can
use to describe what happened in kdom/ksvg2/kcanvas development.

KCanvas has been rewritten some weeks ago to go back from the
old chunk-based rerendering algorithms to a new strategy, using
z-ordered trees (well read the source Smiling - it turned out to
perform much faster, especially when panning/zoominf, it also
simpified internal KCanvas code a lot, and yes it's much more OOP.

ksvg2 is being stabilized & markers have been added recently.
A lot of work can still be spent in the Animations area, though
the framework if pretty much done now, in a clean & stable way.

I'm, perosnally, more into callgrinding (aka. profiling) ksvg2,
in order to load a 33 MB (yes 33) svg data file, in short time.
Short time currently means minutes & extensive memory usage (factor 10).

Now what to do to optimize that bugger? Easy answer: Safari WebCore
contains a lot of optimizations (ie. in the css area) which speed up
the whole parsing/restyling etc. really in a great way. Also memory
usage is much reduced. So first thing I did last weekend is merging
in some WebCore changes, which I stopped for now because of a simple
reason: I'm also porting khtml to kdom in the meanwhile, and well
the internal concepts in for instance the css engine changed heavily.

So I spent the last days syncing khtml's with kdom's css stuff, which
I just commited to SVN. Then I'll continue khtml2 (new fancy codename Eye-wink.

Once we have ksvg2 & khtml2 both on top of kdom, I will definately work
on the Safari optimizations, before I'll concentrate on CDF (Compound
Document Format; ie. svg in xhtml...) again. As you see a LOT of work
for me recently, but hey I'll hope it'll improve our all future Smiling

Thanks for listening until here, I'll keep you updated over the next
days - ah and for the curious: yes we'll port everything to Qt4, once
the khtml2 -> kdom port is somewhat functional.... Long live KDE!

WildFox, aka. Niko Smiling

» wildfox's blog | login or register to post comments | 597 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
snailcoder's picture

AGG usage agg::rasterizer_scanline_aa<> m_ras;

Submitted by snailcoder on Mon, 10/24/2005 - 04:04.

Hi,I am new to KSVG and AGG.I would like to know how AGG rentering buffers are used within KSVG.I could not find any code that supports my notion of AGG usage, wherein a rendering buffer can be used to render the scanlines.Any helpful hints will be greatly appreciated.

Thanks,
Snailcoder

» login or register to post comments
mcseem's picture

About SVG

Submitted by mcseem on Sun, 09/11/2005 - 19:55.

It looks like mister WildFox isn't very active here and my post is a late one.

However, I'd like to note that SVG with its XML/DOM paradigm is kinda strange. With typical XML DOM structure it takes 10-100 times more memory than the original SVG file. I also have a 30MB SVG file, and it takes about an hour plus half a gig of memory to render it in Adobe SVG viewer.

I create a plain binary stream in memory (as a reflection of the original SVG), and then play it in a SAX-like mode to render.
So that, on my old P4 1.9GHz:
This file (32 meg) takes about 16 seconds to parse and only 3.2 seconds to render. And it consumes no more than 35 megs of memory.
The screenshots:
http://antigrain.com/stuff/svg/arbeitskopie_esv1.jpg
http://antigrain.com/stuff/svg/arbeitskopie_esv2.png
http://antigrain.com/stuff/svg/arbeitskopie_esv3.png

Well, of course it's a plain data stream, not usable as DOM. But do we really need DOM to display SVG? Smiling

McSeem
http://antigrain.com

» login or register to post comments
zander's picture

DOM is not implementation; its API.

Submitted by zander on Wed, 09/21/2005 - 19:03.

The DOM design is an API that you need for complex stuff like svg; what people mistake (mostly in the C++ world) is that it implies you have to load everything, you don't, you just need to let the user of the (dom) API think you are doing that.

There are implementations of DOM out there (but mostly done in garbage collecting languages) they are a LOT faster and more memory efficient because they implement dom differently. By using a SAX backend, for example. The user of the DOM APi will never notice, naturally, except for the high speed he suddenly gets.

» login or register to post comments
wildfox's picture

TimeLine

Submitted by wildfox on Thu, 05/19/2005 - 00:52.

Hi Bram & co Smiling

the timeline for this stuff is definately KDE4.
khtml is one of the core components in kde, whose
core can't be just completely changed in a
non-major release (think of BIC...)

But well for KDE4, we hopefully have a killer
achievment compared to other desktop environemnts...

Bye
Bye
Niko

» login or register to post comments
pipitas's picture

The Alps are behind

Submitted by pipitas on Wed, 05/18/2005 - 19:59.

It may be a log way to Rome -- but it looks like you'll have left behind the Alps very soon. So.... after the troubles of the mountains, now the troubles of the plains are looming.

Eye-wink

Really great achievement. All you report here sounds pretty exciting. Keep us in the loop!

Cheers,
Kurt

» login or register to post comments
bram schoenmakers's picture

Way to go!

Submitted by bram schoenmakers on Wed, 05/18/2005 - 19:30.

This sounds really good. I'm very impressed with your, Rob's and Frans' contributions to these areas. I don't read all your commit messages, since they look like acrabadabra to me, but I feel you're making great progressions.

Do you have a timeline? In which release we will see the first application using kdom/ksvg/kcanvas? KDE 3.5 or do we have to wait until KDE 4?

Bram Schoenmakers
KDE Netherlands (www.kde.nl)

» login or register to post comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.