Difference between revisions of "Hackfest2015 Topics"

Revision as of 09:17, 20 March 2015

Please add topics you would like to discuss or work you would like to see done at the hackfest.

Other pages: Hackfest 2015, Hackfest2015 Attendees.

Discussions

SVG 2 strategy (Tav)

Overview/rundown of relevant new SVG2 features. What are they, what will need done to implement them?
How do we handle fallbacks?
When do we add things to the GUI? (When three browsers offers support?)

Program flow (Tav)

Diagram how Inkscape behaves/should behave on:
- Opening a file.
- Changing a style item (e.g. 'fill').
- Moving a node.
- Deleting an item.
  - Comment: Deleting an item causes Inkscape to create a new SVG document with containing the deleted item to allow pasting.

Motivation

Add a few random print statements in Inkscape and you'll see that Inkscape visits certain functions more often than one would think it should. Having well defined diagrams will allow developers to clean up existing code and to better understand what needs to be done to add new features. I've noticed that we suffer from "cargo cult programming" where people add functions without fully understanding if they are truly needed.

Ideas
- Better, easily referenced API documentation
- Code reviews
- `linux perf` can be used to identify performance critical functions

Comments from Krzysztof

This is a pretty big problem right now. The flow looks like this:

Something is updated in the SP tree

updateRepr() is called
new XML is written
XML modification listeners fire
SP tree is re-read from the XML
A recursive call to update() is made
Each of those update calls updates the rendering tree in turn.

As a result, changing the document height triggers a full update of the rendering tree, even though almost nothing changes.

The current approach makes it impossible to introduce errors that cause the XML and the SP tree to go out of sync, at the cost of performance. We could discuss what to do about this.

Website (DoctorMO)

How do people feel about it's current functions
How should we move it forwards?
Plans for mailing list migrations.
Getting developers set up with local copies for hacking.

Refactoring (AV)

Can we decide on a roadmap to work with new APIs and compilers? How do we minimize breakages for downstream users? Can we balance risk with reward? How does each migration benefit the developers, package maintainers and end users?

Some possible changes to discuss:

Moving to C++11
- code cleanup/maintainability
- improved data structures/templating
Adding a hard Cairo 1.14 dependency
- Fix bitmap downscaling issue
Gtk+ 3 migration
- Get rid of lots of conditional code
- Get rid of embedded GDK library fork
- Some "cleaner" API available
- How do we handle canvas flickering/rendering issues?
C++ification
- Migrate widgets/dialogs to Gtkmm
- Get rid of popt
- Get rid of GObject usage
Removing 3rd party Library dependencies from version control
Change how we're utilizing 3rd party libraries
- Stop using Poppler internals, use the proper API via poppler-glib (https://bugs.launchpad.net/inkscape/+bug/239544)
- Use newer Pango-Cairo text/glyph APIs (https://bugs.launchpad.net/inkscape/+bug/420822)

Roadmap Planning (Bryce)

Prioritize feature and infrastructure development work for next several releases.

Fundraisers (Bryce)

Brainstorm future fundraising ideas.

Community Development (Bryce)

Championing FOSS ideals generally
Expanding userbase
Building up a strong evangelist user community
Recruiting newbie developers, encouraging involvement, and mentoring
Re-connecting with old timers
Promoting existing developers into leadership roles

Hacking

Invert coordinate system (Tav)

If there was ever a good moment to do the coordinate system flip, this is it. (should coordinates be configurable in relation to the canvas?)

CMake (Bryce)

A while back someone made a valiant attempt to get Inkscape built with cmake, but if this ever worked it's bitrotted to where it doesn't work presently. Hack it back into working shape on Linux, Mac, and Windows. Write up evaluation.

Hardware Acceleration Experimentation (Bryce)

Create experimental branch using Cairo-GLX as the rendering backend. Evaluate rendering performance. Brainstorm follow up work.

@@ Line 11: / Line 11: @@
 * How do we handle fallbacks?
 * When do we add things to the GUI? (When three browsers offers support?)
 === Program flow (Tav) ===
@@ Line 29: / Line 30: @@
 ** Code reviews
 ** `linux perf` can be used to identify performance critical functions
+==== Comments from Krzysztof ====
+This is a pretty big problem right now. The flow looks like this:
+Something is updated in the SP tree
+# updateRepr() is called
+# new XML is written
+# XML modification listeners fire
+# SP tree is re-read from the XML
+# A recursive call to update() is made
+# Each of those update calls updates the rendering tree in turn.
+As a result, changing the document height triggers a full update of
+the rendering tree, even though almost nothing changes.
+The current approach makes it impossible to introduce errors that
+cause the XML and the SP tree to go out of sync, at the cost of
+performance. We could discuss what to do about this.
 === Website (DoctorMO) ===