Re: [Inkscape-devel] Better hrefs

[Krzysztof Kosiński <tweenk.pl@gm...>]

>> - no memory allocations when adding a reference = better performance.
> That may or may not be true. However the bottom line for performance  
> items is to get solid metrics before and after.
> 
ObjectRefBase acts as an intrusive list. Look here:
http://www.boost.org/doc/libs/1_39_0/doc/html/intrusive/performance.html
In particular look at the back insertion / deletion benchmark (what we're
doing when adding or replacing a reference) - it shows at least 3x better
performance for an intrusive list of small objects.



> Some of the issues are nice. However the overall impression I get  
> here is of a system that breaks encapsulation.
> 
In what way? It doesn't try to refer to implementation details of any
particular SPObject. It just stores some of the data that's passed to its
methods in some place. If this solution breaks encapsulation, then virtual
functions do as well (we could have a virtual function that returns a list
of references but that would result in a LOT of error prone boilerplate,
which this solution avoids completely).



> The signals part also raises some major issues. At the moment we have  
> two trees of data (SPObject *and* xml repr) that tend to get out of  
> sync.
This issue is not related to the problem I'm trying to solve at all...



> Also it is good that you've seen the id's as a problem. The code  
> early on needed to put an id attribute on every single XML element.  
> We have cleaned up much in the code and should be able to further  
> attack things on that point. Why is this pertinent? Well, if one has  
> id's on everything then then ID changing and clash prevention is a  
> huge problem. However, if instead of having thousands of IDs in a  
> document, one only has a dozen then the problem is a completely  
> different one, with different parameters, scaling needs, etc.
> 

The fact that you don't have IDs on every document doesn't change anything:
It's sufficient to open the same document twice, modify one of them, and
paste from one to the other to get an ID conflict. So we still need those
capabilities.



> I guess what I'm trying to point out is that instead of focusing on  
> an optimized list structure,
The list structure is only a means to an end, which I outlined at the
beginning: to be able to iterate over references to an object, and to
iterate over references in an object. Those very generic capabilities will
make a lot of code simpler, and they're not really related to the structure
of the document. The concept of reference between objects will not go away
no matter how we change the SP tree.

Regards, Krzysztof
-- 
View this message in context: http://www.nabble.com/Better-hrefs-tp24939304p24962143.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Re: [Inkscape-devel] Preparing for Feature Freeze

[bulia byak <buliabyak@gm...>]

On Thu, Aug 13, 2009 at 4:49 PM, the Adib<theadib@...> wrote:
> I would vote for:
>
> 376068           Inkscape 0.46_5 Segmentation fault on gradient edit

fixed in 22079

> 376068           Inkscape 0.46_5 Segmentation fault on gradient edit
> this is an transition problem from inkscape floating point precistion
> to cairo-based integer calculation
> the calculated value is a NaN.
> In this case the crash can be prevented by ignoring the element or so.

you gave the same bug number?

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Re: [Inkscape-devel] Re : Preparing for Feature Freeze

[bulia byak <buliabyak@gm...>]

On Thu, Aug 13, 2009 at 5:11 AM, Nicolas Dufour<nicoduf@...> wrote:
> #304018 Crash when using LPE with node tool selected (https://bugs.edge.launchpad.net/inkscape/+bug/304018)

fixed in 22074, please test

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Re: [Inkscape-devel] Preparing for Feature Freeze

[the Adib <theadib@go...>]

I would vote for:

376068  	 Inkscape 0.46_5 Segmentation fault on gradient edit
an gui element is accessed in the dialoge after the removal from screen
currently the crash comes from assert function thus is can be
converted to "close this dialogue" or something else

376068  	 Inkscape 0.46_5 Segmentation fault on gradient edit
this is an transition problem from inkscape floating point precistion
to cairo-based integer calculation
the calculated value is a NaN.
In this case the crash can be prevented by ignoring the element or so.

Adib.

On Thu, Aug 13, 2009 at 1:16 AM, Joshua A. Andler<scislac@...> wrote:
> Hey All,
>
> It appears that the Frost is nearing completion, and the Feature Freeze
> will be setting in soon. Given this, it's probably a good time to start
> putting together a list of release blocker bugs, as well as discuss if
> any features need to be pruned due to them being incomplete.
>
> For reference, here are the bugs that are still milestoned for 0.47:
> https://edge.launchpad.net/inkscape/+milestone/0.47
>
> Is anyone aware if there currently any major platform specific bugs like
> we had around 0.46? (win32 printing issue is what I speak of)
>
> Also, JonCruz, should we hold back the "Auto" swatch palette from this
> release?
>
> At this point I want to again remind people to ensure that the release
> notes are as up-to-date as possible! Please take a moment to ensure that
> your improvements/enhancements/new features are all mentioned with a
> brief explanation where necessary.
>
> Thanks to everyone for your contributions!
>
> Cheers,
> Josh
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

Re: [Inkscape-devel] Preparing for Feature Freeze

[~suv <suv-sf@us...>]

On 13/8/09 01:16, Joshua A. Andler wrote:
> It appears that the Frost is nearing completion, and the Feature Freeze
> will be setting in soon. Given this, it's probably a good time to start
> putting together a list of release blocker bugs, as well as discuss if
> any features need to be pruned due to them being incomplete.

PDF export: text to path still broken

Bug #388257 “Inkscape 0.47Pre: PDF/PS Export 'Text to Paths' gives
inconsistent results”
<https://bugs.launchpad.net/inkscape/+bug/388257>;

numeric precision crash:

Bug #399604 “'malloc: *** error' after changing numeric precision to 1
or 2”
<https://bugs.launchpad.net/inkscape/+bug/399604>;

technical drawing: geometric bbox mode barely useful for precise values

Bug #190557 “resize of object or group by entering a numeric size
results in a different size.”
<https://bugs.launchpad.net/inkscape/+bug/190557>;

> Is anyone aware if there currently any major platform specific bugs like
> we had around 0.46? (win32 printing issue is what I speak of)

not working features on OS X:

Bug #390024 “raster image extensions fail on osx: missing ImageMagick
config files/resources”
<https://bugs.launchpad.net/inkscape/+bug/390024>;

Bug #373514 “No Script Console on Mac OS X”
<https://bugs.launchpad.net/inkscape/+bug/373514>;

~suv

[Inkscape-devel] Quick File Import Test

[Tavmjong Bah <tavmjong@fr...>]

Hi,

	I just did a quick File Import Test. I did not test all possibilities.
Here are a couple problems:

1. .wmf There are two options. One via Uniconverter and the other from
GDK. Do we need both?

2. Images in PDF appear to be imported upside down.

					Tav

Re: [Inkscape-devel] Preparing for Feature Freeze

[Chris Morgan <chris.morganiser@gm...>]

All the Windows-specific issues that I'm aware of have been fixed now, and
I've done all the work I'm doing for a while fixing up the Windows installer
(still got uninstallation routine optimisation and more complex language
stuff to add in, but that'll need quite a bit of string translation as
well).  Also all the Inkscape Portable-related issues have been ironed out
(thanks particularly to Jon Cruz for committing my first patch for an
alternative setting storage location and theAdib for working out the export
dialogue file chooser window :-) )
I'm looking forward to the release of 0.47 (especially so that Inkscape
Portable will be released at PortableApps.com :D )!

On Thu, Aug 13, 2009 at 9:16 AM, Joshua A. Andler <scislac@...> wrote:

> Hey All,
>
> It appears that the Frost is nearing completion, and the Feature Freeze
> will be setting in soon. Given this, it's probably a good time to start
> putting together a list of release blocker bugs, as well as discuss if
> any features need to be pruned due to them being incomplete.
>
> For reference, here are the bugs that are still milestoned for 0.47:
> https://edge.launchpad.net/inkscape/+milestone/0.47
>
> Is anyone aware if there currently any major platform specific bugs like
> we had around 0.46? (win32 printing issue is what I speak of)
>
> Also, JonCruz, should we hold back the "Auto" swatch palette from this
> release?
>
> At this point I want to again remind people to ensure that the release
> notes are as up-to-date as possible! Please take a moment to ensure that
> your improvements/enhancements/new features are all mentioned with a
> brief explanation where necessary.
>
> Thanks to everyone for your contributions!
>
> Cheers,
> Josh
>
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


Thanks,

Chris Morgan <chris.morganiser@...>


I don't need a quote in my signature.  It's hard enough surviving as it is
without having to find a meaningful quote.  Will you forgive me?  Or don't
you read this bit?

Re: [Inkscape-devel] File Export Tests Update

[Chris Morgan <chris.morganiser@gm...>]

>
> .xaml (C) Circle/star/text translations wrong. No patterns. (Tested by
> reimporting into Inkscape.)

That's actually not a fair test.  As far as immediate usage by Silverlight
goes, it deserves an F - it encodes things wrong or something (I can get
more specific details from my Dad if you like, from when he switched from
SVG to Silverlight with his WaterSums software) and so they don't work at
all without a fair chunk of fixing up in a text editor.  Inkscape's XAML
import filter suffers from similar things.


-- Chris Morgan <chris.morganiser@...>


I don't need a quote in my signature.  It's hard enough surviving as it is
without having to find a meaningful quote.  Will you forgive me?  Or don't
you read this bit?

Re: [Inkscape-devel] Re : Preparing for Feature Freeze

[Maximilian Albert <maximilian.albert@go...>]

2009/8/13 Nicolas Dufour <nicoduf@...>:

> Two very annoying bugs:
>
> #307195 crash with two inkscape instances when changing layer (https://bugs.edge.launchpad.net/inkscape/+bug/307195)

I actually tried to look into this a while ago. I seem to remember
that the (way towards a) solution revealed some more fundamental
issues, but I can't remember exactly what it was. I'll try to dig it
up, but if I'm unlucky it may take a few days before I get around to
doing it.

Max

[Inkscape-devel] Re : File Export Tests Update

[Nicolas Dufour <nicoduf@ya...>]

Hi,


> De : Tavmjong Bah <tavmjong@...>
> .emf: (?) Not tested.. Windows only.

Shapes are OK.
Gradient, pattern, and text shadow are missing.
Clipping doesn't work (only the clipping rectangle is shown).

C or D?

Cheers,
--
Nicolas



      

Re: [Inkscape-devel] Preparing for Feature Freeze

[Tavmjong Bah <tavmjong@fr...>]

On Wed, 2009-08-12 at 16:16 -0700, Joshua A. Andler wrote:
> Hey All,
> 
> It appears that the Frost is nearing completion, and the Feature Freeze
> will be setting in soon. Given this, it's probably a good time to start
> putting together a list of release blocker bugs, as well as discuss if
> any features need to be pruned due to them being incomplete.

#407893: Text Tool attributes messed up.

#382313: Image Filter broken for external images. This is a serious
regression in my opinion.

#397075: Inkscape crashes adding image effect in filter editor.

Important... but maybe not a blocker:

#389130 Inkscape PNG transparency display appearance does not match
export and other standard applications

Tav

[Inkscape-devel] File Export Tests Update

[Tavmjong Bah <tavmjong@fr...>]

Hi,

	Here is an update of my File Export tests.

	The SVG files I used for the tests can be found at:

http://tavmjong.free.fr/INKSCAPE/MANUAL_v15Draft/images/FILES/FileExportTest.svg
http://tavmjong.free.fr/INKSCAPE/MANUAL_v15Draft/images/FILES/FileExportTest_PlainText.svg
http://tavmjong.free.fr/INKSCAPE/MANUAL_v15Draft/images/FILES/FileExportTest_NoText.svg

	A draft of my File Export section of my book can be found at:

http://tavmjong.free.fr/INKSCAPE/MANUAL_v15Draft/html/File-Export.html

You can see the results of exporting for most formats.

	I assigned a letter grade (A best, F fail) to each export based on what
could be expected in a perfect export, taking into account the
limitations of the export file format.


File Format:

.ai: Removed (poorly supported old AI format, AI since 2001 can directly
import SVG).

.dfx: Two routines:

	(B) AutoCAD DFX: Missing star shape (perhaps as it is partly off page).

	(C) Desktop Cutting Plotter: Missing rectangle, Star in wrong place.
Same errors as in HPGL export. FX export gets in right.

.emf: (?) Not tested. Windows only.

.eps: (A) Cairo imposes restriction that bounding box must be smallest
rectangle around objects in exported drawing.

.fx:  (B) Gradients defined but not placed correctly. Patterns are
referenced but not defined.

.gpl: (A)

.hpgl (C) See .dfx.

.odg (C) One small translation error. Text and paths may be invisible.

.pdf (A)

.plt (C) Circle missing. Cannot have references to fonts in SVG file.
(Uniconvertor)

.png via Cairo (B) Missing rasterizing filter support but does a better
job at patterns.

.pov (F) Broken, extra output lines.

.ps (A)

.sk1 (F) Fails with error message.

.svgz (A/F) Double entries. Second one fails. Any problem with deleting
external export option?

.svg with Scour (A, after bug with ellipses fixed)

.tex Two options:

	PSTricks (A) Patterns, gradients, etc. not supported but not expected
to be.

	PSFrag (B) Cairo font subsetting requires hand editing strings.

.wmf (C) Circle missing. Cannot have references to fonts in SVG file
(Uniconvertor)

.xaml (C) Circle/star/text translations wrong. No patterns. (Tested by
reimporting into Inkscape.)

.xcf (A)

.zip (A)

[Inkscape-devel] Re : Preparing for Feature Freeze

[Nicolas Dufour <nicoduf@ya...>]

Hi,

> De : Joshua A. Andler <scislac@...>
> It appears that the Frost is nearing completion, and the Feature Freeze
> will be setting in soon. Given this, it's probably a good time to start
> putting together a list of release blocker bugs, as well as discuss if
> any features need to be pruned due to them being incomplete.

Two very annoying bugs:

#304018 Crash when using LPE with node tool selected (https://bugs.edge.launchpad.net/inkscape/+bug/304018)
#307195 crash with two inkscape instances when changing layer (https://bugs.edge.launchpad.net/inkscape/+bug/307195)
They lead to a crash, are regressions, and appear in very common situations. Thus I think they are release blockers.

And three incomplete (or not working) features:

#346721 Segfault after opening scripts dialog (https://bugs.edge.launchpad.net/inkscape/+bug/346721)
Not very annoying (I'm not sure lots of users use it) but since it's an UI menu entry, it should work or be removed (also a regression). It should not be too hard to fix (see bug report).

#179452 export to openclipart.org in dev version (https://bugs.edge.launchpad.net/inkscape/+bug/179452)
I've recently postponed and lowered the report. It should be disabled in 0.47.

#319107 Jabber whiteboard doesn't work (https://bugs.launchpad.net/inkscape/+bug/319107).
Should also be disabled in 0.47.

> Is anyone aware if there currently any major platform specific bugs like
> we had around 0.46? (win32 printing issue is what I speak of)

#166678 Paper size or orientation are not used when printing (https://bugs.edge.launchpad.net/inkscape/+bug/166678) and
#220360 win32 fails to print in large format (A0) (https://bugs.edge.launchpad.net/inkscape/+bug/220360) are now fixed!

> At this point I want to again remind people to ensure that the release
> notes are as up-to-date as possible!

And create a new Keys and Mouse reference for 0.47 (22062 is linked to http://inkscape.org/doc/keys046.html).

Cheers,
--
Nicolas



      

Re: [Inkscape-devel] Preparing for Feature Freeze

[Jon A. Cruz <jon@jo...>]

On Aug 12, 2009, at 4:16 PM, Joshua A. Andler wrote:

>
> Also, JonCruz, should we hold back the "Auto" swatch palette from this
> release?

The next few days should show this. Among other slowdowns, X11  
stopped working for my on OS X 10.4.x. I'll probably be able to go  
into linux and work on this, but it did block even remote X from a  
workflow.

Of course, if things don't settle out quickly then it is very easy to  
do an #ifdef so that individuals can turn it on to experiment with,  
yet leave it out for the actual release builds.

Re: [Inkscape-devel] Better hrefs

[Jon A. Cruz <jon@jo...>]

On Aug 12, 2009, at 8:41 AM, Krzysztof Kosiński wrote:

> Here is my idea. We define a three-way smartpointer that looks like  
> this:


Well... first I'd avoid calling it a "smartpointer". That tends to  
wander into existing terminology for things that are very often  
poorly used.


> Why this is better than keeping pointers to the references in  
> std::list or
> std::vector?
> - no memory allocations when adding a reference = better performance.

That may or may not be true. However the bottom line for performance  
items is to get solid metrics before and after. Also a key is to only  
optimize something that is shown to be a performance bottleneck.

Unfortunately I've often seen micro-optimizations lead to macro- 
degradation.


> - removing a reference is much simpler, because finding it in the  
> list is
> not needed.
> - signals can be put in the ObjectRef class.
> - simple and elegant implementation.

Some of the issues are nice. However the overall impression I get  
here is of a system that breaks encapsulation. We should look to use  
this more in a situation where "smaller" owned things do not know  
about things that own them, etc.

While it does strike me as good code, it also looks like a less-than- 
efficient algorithm/architecture.

The signals part also raises some major issues. At the moment we have  
two trees of data (SPObject *and* xml repr) that tend to get out of  
sync. Among other things there are several layer bugs related to  
that. What we probably should focus on is a higher level solution  
that accounts for the two parallel trees, signals, event bubbling,  
even canceling, etc. I think that will bear more long-term fruit.

Also it is good that you've seen the id's as a problem. The code  
early on needed to put an id attribute on every single XML element.  
We have cleaned up much in the code and should be able to further  
attack things on that point. Why is this pertinent? Well, if one has  
id's on everything then then ID changing and clash prevention is a  
huge problem. However, if instead of having thousands of IDs in a  
document, one only has a dozen then the problem is a completely  
different one, with different parameters, scaling needs, etc.

I guess what I'm trying to point out is that instead of focusing on  
an optimized list structure, we need to look at an efficient overall  
solution for the whole use case of Inkscape, including parallel data  
trees, shadow trees, event propagation life-cycles, etc. Then as we  
drill-down on the larger problem, we might hit on tunings to use this  
data type. Or we might see a need for a few similar-yet-distinct types.