From batik-users-return-4224-apmail-xml-batik-users-archive=xml.apache.org@xml.apache.org Tue Sep 09 20:51:06 2003 Return-Path: Delivered-To: apmail-xml-batik-users-archive@www.apache.org Received: (qmail 89819 invoked from network); 9 Sep 2003 20:51:06 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Sep 2003 20:51:06 -0000 Received: (qmail 15969 invoked by uid 500); 9 Sep 2003 20:50:37 -0000 Delivered-To: apmail-xml-batik-users-archive@xml.apache.org Received: (qmail 15924 invoked by uid 500); 9 Sep 2003 20:50:37 -0000 Mailing-List: contact batik-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: "Batik Users" Delivered-To: mailing list batik-users@xml.apache.org Received: (qmail 15828 invoked from network); 9 Sep 2003 20:50:35 -0000 Received: from unknown (HELO melchior.redchili.dyndns.org) (193.83.77.225) by daedalus.apache.org with SMTP; 9 Sep 2003 20:50:35 -0000 Received: from localhost (localhost [127.0.0.1]) by melchior.redchili.dyndns.org (Postfix) with ESMTP id 31D3B52E for ; Tue, 9 Sep 2003 22:53:57 +0200 (CEST) Received: from gmx.at (redchili.home [192.168.1.20]) by melchior.redchili.dyndns.org (Postfix) with ESMTP id 1D8776B8 for ; Tue, 9 Sep 2003 22:53:52 +0200 (CEST) Message-ID: <3F5E3D1F.9050701@gmx.at> Date: Tue, 09 Sep 2003 22:50:39 +0200 From: =?ISO-8859-1?Q?Reinhard_Brandst=E4dter?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030808 X-Accept-Language: en MIME-Version: 1.0 To: Batik Users Subject: Re: General Discussion: Performance References: <5.1.0.14.2.20030907140923.01c8c868@pop.kundenserver.de> <3F5B4E52.3050805@gmx.at> <3F5C3489.2050106@cs.rutgers.edu> <3F5C7667.6090000@Kodak.com> In-Reply-To: <3F5C7667.6090000@Kodak.com> X-Enigmail-Version: 0.76.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: by AMaViS 0.3.12 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Thomas DeWeese wrote: > Do the elements overlap? > > If so the problem is most likely that we have to draw the previous > 200 elements to put the last element on top - we don't try and optimize > a solid fill object being appended to the _very_ end of the document. > > If they don't overlap then I am a little suprised to see it slow down. > Also I think 1.5 had a reoccurance of a bug that caused all siblings to be > rerendered when an element was added to a group - this was fixed short > after in CVS so you might try that. Well, yes alway the last 20 elements or so do overlap. The document structure is fairly flat, most of the elements are direct childs of the svg element itself. Reinhard -- Reinhard Brandstaedter r.brandstaedter@gmx.at GPG: 0x033B81DB - Student of Computer Science - J.K. University of Linz - - - - http://adelaide.dnsalias.net - --------------------------------------------------------------------- To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For additional commands, e-mail: batik-users-help@xml.apache.org