2010/2/2 Joshua L. Blocher <verbalshadow@...400...>:

We didn't move to Dwarf2 to for the performance gains. We moved to it because of it superior Debug handling and to bring all our major platform into alignment. It has help us debug issues we would not have been able to figure out when using SJLJ     .

I think MinGW uses Dwarf2 debug information regardless of its exception handling model.

Reasons SJLJ specifically is bad: -SJLJ is much worse in terms of performance efficiency, unusably so in some cases

We are not one of those cases. There are about 100 "try" blocks in Inkscape, none of them in the renderer.

-Other modern targets are using Dwarf, and SJLJ implementation quality will decrease over time.

But for now on Windows the quality of SJLJ implementation is higher than the quality of Dwarf2 implementation.

Dwarf is good:

• Unlike SJLJ, a quality implementations are able to unwind SEH (Structured

Exception Handling on Windows) frames properly.

But the Windows implementation can't, at least for now. When it's ready (hopefully it's fully working in GCC 4.5) the devlibs can be rebuilt again. I left detailed notes on the wiki, so that others can do it if necessary. http://wiki.inkscape.org/wiki/index.php/Inkscape_Devlibs

Regards, Krzysztof

I don't know enough about the differences between SJLJ and Dwarf2. What I do know is that Inkscape hardly uses exceptions, and where we do use it across libraries, it crashes on Windows. I feel https://bugs.launchpad.net/inkscape/+bug/173116 is a very very *very* serious bug, and will definitely move people away from Inkscape. If we can fix it by changing back to SJLJ without clear disadvantages, we should do it. Bob mentions Dwarf2 will give better backtraces, do we have an example of this?

Ciao, Johan

-----Original Message----- From: Joshua L. Blocher [mailto:verbalshadow@...400...] Sent: Tuesday, February 02, 2010 19:30 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] IMPORTANT: Windows compiler change

...

However, it requires changing the compiler. To build

Inkscape and all

...

other C++ libraries, I used TDM-GCC (a patched build of

MinGW) version

...

4.4.1 with SJLJ unwinding. We don't use exceptions in performance critical code, so bothering with Dwarf2 to get a minimal perf gain while substantially increasing code size doesn't seem worth

it. (SJLJ

...

gtkmm is 3x smaller than the Dwarf2 one!) http://www.tdragon.net/recentgcc/

We didn't move to Dwarf2 to for the performance gains. We moved to it because of it superior Debug handling and to bring all our major platform into alignment. It has help us debug issues we would not have been able to figure out when using SJLJ .

http://sourceforge.net/mailarchive/forum.php?thread_name=3c78f f030710310739n74901952s3bd3bec6806422d9%40mail.gmail.com&forum _name=inkscape- devel

Reasons SJLJ specifically is bad: -SJLJ is much worse in terms of performance efficiency, unusably so in some cases -Other modern targets are using Dwarf, and SJLJ implementation quality will decrease over time.

Dwarf is good:

• Unlike SJLJ, a quality implementations are able to unwind

SEH (Structured Exception Handling on Windows) frames properly.

• Up to a 3x speed up in EH

Did you ask any developers why we did things the way we did them?

Joshua L. Blocher verbalshadow

W dniu 3 lutego 2010 04:50 użytkownik Jon Cruz <jon@...18...> napisał:

Just to clarify, was this a change committed that now requires all win32 builds to be done with a different compiler, or is this optional for those who want to avoid the specific bugs?

It is required for all Windows builds when using the new devlibs repository.

W dniu 4 lutego 2010 22:40 użytkownik <J.B.C.Engelen@...1578...> napisał:

I just built Inkscape with the new devlibs and compiler, and now dropdown boxes show blank at first, and only show their contents when I mouse over them. Is this caused by the new devlibs? (i'm not able to quickly build a somewhat older version)

Yes. I mistakenly included the 2.18 version of GDK, which has serious regressions on Windows. This problem is fixed in revision 13 of devlibs (just committed).

Regards, Krzysztof