Ichthyostega
ce3713d872
There is a built-in limitation, which now is even lowered to 100000 pixels horizontally. With the techniques introduced in this changeset, it seems possible to support more -- yet this would be a case of unnecessary genricity; handling such large numbers will drive more computations into the danger zone, and doing so incurs cost in terms of testing and debugging. Placing that into context, contemporary displays are not even 4K on average, and it does not look likely even for cinema display to go way beyond 8k -- so yes, I want display hardware with 100000 pixels!! The key takeaway of this changeset: - can calculate px = trunc(zoomFactor * duration) step wise, even when the direct calculation would lead to wrap-around - can safely adjust and fix the zoomFactor using Newton approximation |
||
|---|---|---|
| .. | ||
| ctrl | ||
| interact | ||
| model | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| gen-node-location-query.hpp | ||
| README | ||
| session-structure-mapping-test.cpp | ||
| test-gui-test.cpp | ||
GUI backbone tests The tests in this subtree are a bit special: they cover the generic and backbone internals of the Lumiera GTK GUI. They are linked against the complete GUI-module (gui plugin), and thus may use all related ABIs. Yet these tests are *deliberately* compiled without any GTK, GTKmm or SigC includes. This effectively rules out the use, even indirectly, of any GTK widgets and APIs -- forcing the covered GUI backbone entities to stay clean and generic at API level. This is a decision done on purpose. The concrete GUI framework technology shall be treated as an implementation detail. There is no point in writing tests which click buttons in the GUI -- better delegate any significant logic or functionality to GUI agnostic components. GUI is meant to be a presentation layer and must not develop intelligence on its own.