Backlog of Qt and QtWebKit problems

Qt problems

Description	Branch	Landed in
ARM optimized qdrawhelper is only enabled for RCVT (symbian) . The needs to be transferred to gcc inline assembly. This will optimize memfill, Source, SourceOver and some blend functions.
ARMv6 should be auto detected. Currently arm/armv6 can be passed as -embedded options. The benefit of ARMv6 in src/corelib is the use of atomic load and exchange, instead of the old "swap" extension. __ARCH_ARM_6__ should be used to detect it.
Enabled pld (preload) in qdrawhelper for ARMv5te and upwards
Optimize scrolling of Windowsurfaces. Either optimize memcpy/memmove or consider using a tile based window surface
QImageReader deserves some optimatations. E.g. decode to the QImage provided to the decoder, do not parse every gif when trying to determine the size.	​image-changes
Cut down on usage of QImage::scanLine inside Qt. This was already done in the GIF and PNG decoder.	​image-changes
Make QGifHandler::imageCount scan through the images. This can give a 5% speedup in the image_cycling reduction.
Make picking a QImageIOHandler in QImageReader faster. Currently even the TIFF plugin is asked to handle images.
Consider creating a tile based QImage to allocate image chunks from an image pool with fixed size images
Bring zero-copy to QIODevice... big one. That is good for networking and image decoding.
Consider creating a SharedBuffer that works on tiles/segments
Changes to QHttpNetworkReply to reduce memory reallocations. Reserve some bytes instead of doing QByteArray::append all them time.
Changes to QNetworkReply to remove quadratic runtime in QNetworkReplyHandler and latency fixes	​network-changes
Cut down on the usage of QUrl::toEncoded as it shows up in the profile of starting jobs.
QBENCHMARK results are hard to analyze and compare. We need a single and simple way to say if something is faster or slower. Be a bit like sunpsider, do the same math as well, mention slowest and fastest run.

QtWebKit problems

Bug	Description	Commit
Loading of ​http://en.wikipedia.org/wiki/Maxwell_equations is triggering bad "scheduling". The loading_standalone test has been extracted but is not able to highlight the problem. This is a Qt and QtWebKit issue, it must be understood first.
TCmalloc needs to be tested. Does it make anything faster/slower? How to test memory fragmentation.
The fuzz testing will make QtWebKit go in infinite loops and stop working. This situation needs to be analyzed as this can be a serve reliabality problem.
​#30211	Research a better QImage -> QPixmap migration strategy. Currently we convert every QImage to a QPixmap and this is bad for times where we need to draw a scaled version of the image or will only draw this image once.
​#30293	Loading speed regressed due image changes?
​#30301	Loading bug/API bug on loading amazon in QtEmbedded Linux. Loading does not complete.
​#29279	Decode images to RGB16 or smaller (instead of RGB32) to conserve memory
Go through the Palm changes and consider adopting them. Currently candidates are: Use stack/class memory in CSSParser, use JDCT_Fast for Jpeg decoding (to be achieved with QImageReader to set quality to 49), changes to Cached* to throw away encoded data more early. Palm avoids floating point operation on premultiplied alpha in setRGBA.
​#30740	Using QImageReader::setQuality(49) will use JDCT_IFAST and promises to give a 5% speedup on image_cycling.
​#30210	Create Embedded profile that will tune for embedded usage. This can mean to save memory in favor of speed, add a speed gain by avoiding certain operations, trading image quality for speed
Image decoder changes needs to be measured. Do they make anything faster/slower? Do they consume more or less memory?		​49179ff