It's a long way to Rome.

    wildfox's picture
    By: wildfox
    2005
    18
    May

    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 :-) - 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 ;).

    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 :-)

    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 :-)

    Comments

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.
    Mon, 10/24/2005 - 04:04 — snailcoder
    snailcoder's picture

    AGG usage agg::rasterizer_scanline_aa<> m_ras;

    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

    Sun, 09/11/2005 - 19:55 — mcseem
    mcseem's picture

    About SVG

    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? :-)

    McSeem
    http://antigrain.com

    Wed, 09/21/2005 - 19:03 — zander
    zander's picture

    DOM is not implementation; its API.

    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.

    Thu, 05/19/2005 - 00:52 — wildfox
    wildfox's picture

    TimeLine

    Hi Bram & co :-)

    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

    Wed, 05/18/2005 - 19:59 — pipitas
    pipitas's picture

    The Alps are behind

    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.

    ;-)

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

    Cheers,
    Kurt

    Wed, 05/18/2005 - 19:30 — bram schoenmakers
    bram schoenmakers's picture

    Way to go!

    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)

    Comment viewing options

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