On Wed, 11 Jan 2012 11:35:15 -0200, Thiago Macieira wrote: > A device with limited resources but powerful enough that rasterising SVG > on the fly isn't an issue?
It is - but as our layouts are fix during the runtime of the application this only has to be done once. Later the icons are taken from a pixmap cache ( a further optimization could be to store the cache to disk ). So we only have the penalty of a worse startup time and when we show a page the first time. I have to admit, that we don't need difficult SVG stuff - only small icons/symbols, but they are many: > 1000 icons with about 60k lines XML code today ( see: http://www.fendt.com/int/ tractors_fendtvariotronic_terminalsimulation.asp ). One idea I had was to "precompile" the SVG images on the PC to something QPicture can load. Unfortunately QPicture seems to be forgotten, when Qt4 moved to a floating based rendering. It can't be scaled properly because the boundingRect is not accurate and in integers only. By the way: because of this limitation I started to implement a QPaintDevice in Qwt that is intended to have: - similar record/replay functionality like QPicture ( no save/load ) - the scalability of QSVGRenderer - it can be copied around like QImage/QPixmap > So if you complain that WebKit is big, remember that it's big *because* > of SVG, not in spite of it. SVG is fine as it is something our designer team can create with their tools and QSvgRenderer is good enough to render ( I was not even aware, that it is so limited ). But if there would be any other type of vector graphic format ( even if proprietary ) it would be fine - or even better - too. But at least it would be nice to offer an easy to use API ( if not available yet ) to the WebKit renderer, that renders a SVG document to a QPainter without having to use QGV classes. Uwe _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
