
On Sat, 2013-02-23 at 23:28 +0200, Catalin Ramascanu wrote:
Hello!
My name is Catalin Ramascanu and I am interested in joining Inkscape for this years edition of Google Summer of Code. I am a second year student at the Faculty of Automatics and Computer Science from Bucharest, Romania and I have been using Inkscape for about a month , because currently I am working on a game application for Windows 8.I am really enjoying working with this software and I would really like to make an important contribution to this project. I have read the Inkscape wiki page regarding GSoC 2013 and I am interested in the internal work and performance improvements , specifically the startup time and initialization performance. I have also noticed the slow startup time while working with Inkscape and if it were to be improved , that would be very great. I would like know more information regarding this proposal , why does it take that long to startup and what could the problem be. I am also curios regarding the proposal "Continue C++ification" , could I receive some more information about this idea? I am very familiar with the following programming languages: C , Java , Javascript and can adapt very fast to C++.
Hi Catalin,
Glad to hear you are interested in GSoC with Inkscape!
Start up time seems to be related to loading system fonts. Those with hundreds or even thousands of fonts see long start-up times. You would need to find a way of figuring out where the biggest delays are and find a way to reduce them. There are ways of doing this. To figure out where the delays are one needs to profile the code (Google for "C++ profiling"). If it really is a font-loading problem, one could load the fonts during the idle time of the main program loop rather than loading them all at the very beginning.
Another possible source for long start-up times, and slowness in general is the signaling system in Inkscape. When a change is made in one place signals are emitted so that other placed can be updated. For example, changing what is selected in the drawing emits a "selection changed" signal which causes all the dialogs to be updated. The problems is that more signals are emitted that really necessary leading to the same update code being executed multiple times. Cleaning this up, however, is something that would require a deep knowledge of how Inkscape's internal code works, probably not doable in a GSOC project.
Tav