[Development] The dark side of QtSvg
wargand at gmx.de
Thu Mar 12 17:01:08 CET 2015
> So my wonder is this: if the SVG rendering of QtWebKit/QtWebEngine is modern and solid, why not "extracting" it
> from those monsters and place it into a brand new QtSvg ?
Very easy to ask for something like that. When do you start?
> This would bring two advantages:1- applications that need to render SVG graphics can rely on a small footprint but
> efficient QtSvg library2- QtWebEngine can be built without the SVG support (if needed) to reduce the library footprint.
> Now it's all monolithic and on embedded systems with low memory availability, a 64MB library is a total killer.
This might be. However, if you follow this list, you will now and then read from a Digia developer: Not enough resources.
Very hard to argument against this. Apart from that, superficially your proposal sounds good, but it is a maintenance nightmare.
The Qt project has no real control over the webkit code. Modularizing a non trivial 3rd party product? Keeping it up-to-date?
The only thing where I agree is that their proposal to use the webkit to render SVGs is ridiculous. I did it. On systems where
the webkit stuff was needed and installed anyways. But even then it was a quite unwieldy solution. For systems with memory
More information about the Development