qgraphicsview fitInView hardcoded margins

qgraphicsview's fitInView method adds a margin of 2 to the viewport so the scene is not what the user requests from the specified rect parameter. While the method does only try and guarantee that the rect is within the viewport's view, this is not what most people want - they want 100% of the viewable area in the scene corresponding to 100% of the area of the viewport. This is the way most opengl routines work and is the intuitive way of working. Conversely, specifying a completely arbitrary margin ends up just confusing everybody:

http://www.qtcentre.org/threads/37456-QGraphicsView-unwanted-margin
http://www.qtcentre.org/threads/59530-Unwanted-margin-inside-QGraphicsView-with-Scrollbars
https://stackoverflow.com/questions/19640642/qgraphicsview-fitinview-margins
https://stackoverflow.com/questions/17223547/unwanted-margin-inside-qgraphicsview-with-scrollbars
http://qt-project.org/forums/viewthread/34205
http://www.qtforum.org/article/35467/the-2px-border-problem-in-qgraphicsview.html

For me it caused runway adjustments.

What was the rationale behind this? I cannot see any positive outcomes.

Also some documentation detailing the linear algebra with the transformation fields that the qgraphicsview/scene are using would be nice. After inspecting the transforms that were defined, I didn't expect The m31 and m32 to be nonzero and dx/dy are kind of kept on the side... I'm a little surprised 4x4 matrices, which unify all of these things were not used instead. You can still optimize the exact mults being done as was done in qtransform although with vectorized mults (neon, sse2+), it'll probably be faster than 3x3 special cases as done here and a leaner implementation over all. It would also be very convenient have get/store of qreal[9]'s or overloaded operator() and operator[] so people don't have to call those ugly methods. I really like taking the things that work well in opengl and using them in 2d drawing but I'm seeing gotchas in application...