On 8 March 2015 at 20:55, Gehad Elrobey <[email protected]> wrote: > Thanks lubomir for your clarification. > > When I tested rendering some svg images with QWebView it wasn't slow at all. > So the bottleneck in this process is saving QPicture as SVG?
compared to what we do ATM - rendering the profile QWidget directly to QPrinter which produces vector (Win32 / OSX only), the introduction of SVG which is grabbed from a QWidget then displayed in QWebView which is then rendered to QPrinter surely will slow things down as it introduce an intermediate step (SVG). the alternative - somehow obtain the absolute position of the <div> (jQuery?) where the profile should be located and it's scaled dimensions on the page and then do QProfileWidget->render() at that exact location on top of the already rendered HTML template. this avoids SVG completely! i would like us to test the alternative firs, unless you have objections. surely this won't be that difficult with Javascript / CSS / jQuery: http://stackoverflow.com/questions/683339/how-do-i-find-the-absolute-position-of-an-element-using-jquery if it's way too tricky we can go back to the SVG idea. > > Also we don't have to save the svg images to the disk and render them back > to QWebView, I found that we can access the QWebView requests directly by > extending QNetworkAccessManager class and overridding createRequest() > function, Then we can serve the meta:image/svg requests directly from > memory. do you think this will do any optimization? > i don't think QNetworkAccessManger is needed as we can use QBuffer. see my example a couple of emails above: QByteArray byteArray; QBuffer buffer(&byteArray); QSvgGenerator svg; svg.setOutputDevice(&buffer); ... lubomir -- P.S.: bottom-posting please :-) _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
