2011/3/27 Krzysztof Kosiński
<tweenk.pl@gmail.com>
Hello
I'm not 100% sure yet whether I'll be able to participate in GSoC
2011, but here are my ideas. They can be used by other potential
participants.
1. Selections
A lot of functions in Inkscape operate on the current selection. This
includes things like moving objects to another layer, creating a
bitmap copy, etc. This leads to a lot of unnecessary code duplication
when some other function needs to reuse selection-specific logic in a
way that is not tied to the UI. It also precludes any useful
implementation of scripting (e.g. one that does not need to modify the
user's selection every time a script is run). In order to rectify
this, we should create an object that represents an arbitrary
collection of SVG elements. It would work like the selection we have
now, but would not be tied to any UI elements - it would just
represent an ordered set of elements that can be passed to functions.
2. Fix flowtext
Use svg:switch to fix flowtext. Make svg:switch transparent to the SP
tree - e.g. a switch should not have its own SP element, the active
part of the switch should be transparently included into the SP tree.
This can be accomplished by allowing every object to have more than
one representation.
3. Make XML private
Discussed before. Was the object of a previous year project, but the
main effect of that was mass renaming and moving of code into classes
rather than any meaningful improvement in encapsulation. The main
thing we need is an ability to create SP nodes. Right now we create
XML nodes and rely on SP tree callbacks to construct the SP node for
us.
4. Typed XML tree
The XML tree stores strings, which is rather wasteful and leads to a
lot of boilerplate in SP object implementations. We have enough
knowledge about the document at the XML level to know the type of each
attribute and CSS property based on its name. Storing parsed values
would save space, particularly for embedded images, at the cost of
slightly more expensive saving. GVariant could be used.
5. GTK3 compatibility
This would involve removal of deprecated code, so that Inkscape
compiles with both GTK2 and GTK3.
6. 2geom improvements
Move and rewrite code 2geom to the point where it can take over the
job of livarot, libavoid, etc. Document the new code and make sure it
fits nicely with existing code. The scope of the project could be
limited to implementing Boolean operations on paths.
7. Rendering speed improvements
Further work on the Cairo branch in several small sub-projects:
a) Instead of re-rendering the same pixels every time a new tile of a
filter is rendered, cache them until the rendering is done. The
implementation could involve allocating screen-size bitmaps for each
layer of a filtered object and filling them with data in small
increments.
b) Render editing controls to a separate image that is composited on
top of the drawing, so that what a path outline is highlighted, there
is no need to re-render the object under it.
c) Render each layer of the drawing to a separate image;
alternatively, render 3 images: everything below current layer,
current layer and everything above. This would allow the user to give
us some hints.
Regards, Krzysztof
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel