QGraphicsScene coordinate space larger than INT_MAX, but QGraphicsView scroll broken

[cgomez116]

I have an application where the coordinate space of the QGraphicsScene can and will be much smaller/larger than INT_MIN, INT_MAX (−2,147,483,648, +2,147,483,647, see http://en.wikipedia.org/wiki/Limits.h), i.e. the scene will contain many items with coordinate positions with qreal (double) values much smaller/larger than the INT_MIN, INT_MAX.

But the QGraphicsView inherits QAbstractScrollView, and the scroll bars are limited to an integer range of INT_MIN to INT_MAX, see: http://doc.trolltech.com/4.5/qgraphicsview.html

"QGraphicsView can be used to visualize a whole scene, or only parts of it. The visualized area is by default detected automatically when the view is displayed for the first time (by calling QGraphicsScene::itemsBoundingRect()). To set the visualized area rectangle yourself, you can call setSceneRect(). This will adjust the scroll bars' ranges appropriately. Note that although the scene supports a virtually unlimited size, the range of the scroll bars will never exceed the range of an integer (INT_MIN, INT_MAX). When the scene is larger than the scroll bars' values, you can choose to use translate() to navigate the scene instead."

Has anybody actually figured out how to use translate() to accomplish scrolling in a scene where the coordinate space is larger than (INT_MIN, INT_MAX)? Or do I need to create my own custom scroll bars that use qint64 ranges instead of int ranges?

This seems to me to be a big blunder in GraphicsView implementation, as allowing the scene to contain items with qreal (double) coordinates, but the view can only scroll int coordinates is a huge limitation.

In any case, any suggestions are appreciated, and if someone has already encountered this and has a solution they wouldn't mind sharing (either the algorithm or example code :-) it would be greatly appreciated.

For those who are curious the application involves graphing space/time data with time on the x coordinate, where the times and time ranges will routinely be > than INT_MAX (the time base is in picoseconds). If every time tick is 10 pixels wide, then I am in fact limited to a range of INT_MAX/10 (214,748,364) time units. Thats not a lot of time in a picosecond time base!