| 4 | | ||Description||Branch||Landed in|| |
| 5 | | ||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.|| || || |
| 6 | | ||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.|| || || |
| 7 | | ||Enabled pld (preload) in qdrawhelper for ARMv5te and upwards|| || || |
| 8 | | ||Optimize scrolling of Windowsurfaces. Either optimize memcpy/memmove or consider using a tile based window surface|| || || |
| 9 | | ||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.||[http://qt.gitorious.org/~zecke/qt/zeckes-qt/commits/merge/qimagehandler-changes image-changes]|| || |
| 10 | | ||Cut down on usage of QImage::scanLine inside Qt. This was already done in the GIF and PNG decoder.||[http://qt.gitorious.org/~zecke/qt/zeckes-qt/commits/merge/qimagehandler-changes image-changes]|| || |
| 11 | | ||Make QGifHandler::imageCount scan through the images. This can give a 5% speedup in the image_cycling reduction.|| || || |
| 12 | | ||Make picking a QImageIOHandler in QImageReader faster. Currently even the TIFF plugin is asked to handle images.|| || || |
| 13 | | ||Consider creating a tile based QImage to allocate image chunks from an image pool with fixed size images|| || || |
| 14 | | ||Bring zero-copy to QIODevice... big one. That is good for networking and image decoding.|| || || |
| 15 | | ||Consider creating a SharedBuffer that works on tiles/segments|| || || |
| 16 | | ||Changes to QHttpNetworkReply to reduce memory reallocations. Reserve some bytes instead of doing ''QByteArray::append'' all them time.|| || || |
| 17 | | ||Changes to QNetworkReply to remove quadratic runtime in QNetworkReplyHandler and latency fixes||[http://qt.gitorious.org/~zecke/qt/zeckes-qt/commits/merge/network-changes network-changes] || || |
| 18 | | ||Cut down on the usage of QUrl::toEncoded as it shows up in the profile of starting jobs.|| || || |
| 19 | | ||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.|| || || |
| | 4 | ||Description||Branch||Landed in||Landed Date|| |
| | 5 | ||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.|| || || || |
| | 6 | ||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.|| || || || |
| | 7 | ||Enabled pld (preload) in qdrawhelper for ARMv5te and upwards|| || || || |
| | 8 | ||Optimize scrolling of Windowsurfaces. Either optimize memcpy/memmove or consider using a tile based window surface|| || || || |
| | 9 | ||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.||[http://qt.gitorious.org/~zecke/qt/zeckes-qt/commits/merge/qimagehandler-changes image-changes]|| || || |
| | 10 | ||Cut down on usage of QImage::scanLine inside Qt. This was already done in the GIF and PNG decoder.||[http://qt.gitorious.org/~zecke/qt/zeckes-qt/commits/merge/qimagehandler-changes image-changes]|| || || |
| | 11 | ||Make QGifHandler::imageCount scan through the images. This can give a 5% speedup in the image_cycling reduction.|| || || || |
| | 12 | ||Make picking a QImageIOHandler in QImageReader faster. Currently even the TIFF plugin is asked to handle images.|| || || || |
| | 13 | ||Consider creating a tile based QImage to allocate image chunks from an image pool with fixed size images|| || || || |
| | 14 | ||Bring zero-copy to QIODevice... big one. That is good for networking and image decoding.|| || || || |
| | 15 | ||Consider creating a SharedBuffer that works on tiles/segments|| || || || |
| | 16 | ||Changes to QHttpNetworkReply to reduce memory reallocations. Reserve some bytes instead of doing ''QByteArray::append'' all them time.|| || || || |
| | 17 | ||Changes to QNetworkReply to remove quadratic runtime in QNetworkReplyHandler and latency fixes||[http://qt.gitorious.org/~zecke/qt/zeckes-qt/commits/merge/network-changes network-changes] || || || |
| | 18 | ||Cut down on the usage of QUrl::toEncoded as it shows up in the profile of starting jobs.|| || || || |
| | 19 | ||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.|| || || || |
| 22 | | ||Bug||Description||Commit|| |
| 23 | | ||||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.|||| |
| 24 | | ||||TCmalloc needs to be tested. Does it make anything faster/slower? How to test memory fragmentation.|||| |
| 25 | | ||||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.|||| |
| 26 | | ||[https://bugs.webkit.org/show_bug.cgi?id=30211 #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.|||| |
| 27 | | ||[https://bugs.webkit.org/show_bug.cgi?id=30293 #30293]||Loading speed regressed due image changes?|||| |
| 28 | | ||[https://bugs.webkit.org/show_bug.cgi?id=30301 #30301]||Loading bug/API bug on loading amazon in QtEmbedded Linux. Loading does not complete.|||| |
| 29 | | ||[https://bugs.webkit.org/show_bug.cgi?id=29279 #29279]||Decode images to RGB16 or smaller (instead of RGB32) to conserve memory. The patch introduces new API to Qt.|||| |
| 30 | | ||||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.|||| |
| 31 | | ||[https://bugs.webkit.org/show_bug.cgi?id=30740 #30740]||Using QImageReader::setQuality(49) will use JDCT_IFAST and promises to give a 5% speedup on image_cycling.|||| |
| 32 | | ||[https://bugs.webkit.org/show_bug.cgi?id=30210 #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|||| |
| 33 | | ||||Change CursorQt.cpp to not create QPixmap's right away but only on first load. This will be a minor memory improvement.|||| |
| 34 | | ||[https://bugs.webkit.org/show_bug.cgi?id=27538 #27538]||~~Image decoder changes needs to be measured. Do they make anything faster/slower? Do they consume more or less memory?~~||[https://trac.webkit.org/changeset/49179 49179] [https://trac.webkit.org/changeset/49180 49180] [https://trac.webkit.org/changeset/49181 49181] [https://trac.webkit.org/changeset/49182 49182] [https://trac.webkit.org/changeset/49183 49183] [https://trac.webkit.org/changeset/49185 49185] [https://trac.webkit.org/changeset/49186 49186] [https://trac.webkit.org/changeset/49559 49559]|| |
| | 22 | ||Bug||Description||Commit||Date|| |
| | 23 | ||||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.|||||| |
| | 24 | ||||TCmalloc needs to be tested. Does it make anything faster/slower? How to test memory fragmentation.|||||| |
| | 25 | ||||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.|||||| |
| | 26 | ||[https://bugs.webkit.org/show_bug.cgi?id=30211 #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.|||||| |
| | 27 | ||[https://bugs.webkit.org/show_bug.cgi?id=30293 #30293]||Loading speed regressed due image changes?|||||| |
| | 28 | ||[https://bugs.webkit.org/show_bug.cgi?id=30301 #30301]||Loading bug/API bug on loading amazon in QtEmbedded Linux. Loading does not complete.|||||| |
| | 29 | ||[https://bugs.webkit.org/show_bug.cgi?id=29279 #29279]||Decode images to RGB16 or smaller (instead of RGB32) to conserve memory. The patch introduces new API to Qt.|||||| |
| | 30 | ||||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.|||||| |
| | 31 | ||[https://bugs.webkit.org/show_bug.cgi?id=30740 #30740]||Using QImageReader::setQuality(49) will use JDCT_IFAST and promises to give a 5% speedup on image_cycling.|||||| |
| | 32 | ||[https://bugs.webkit.org/show_bug.cgi?id=30210 #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|||||| |
| | 33 | ||||Change CursorQt.cpp to not create QPixmap's right away but only on first load. This will be a minor memory improvement.|||||| |
| | 34 | ||[https://bugs.webkit.org/show_bug.cgi?id=27538 #27538]||~~Image decoder changes needs to be measured. Do they make anything faster/slower? Do they consume more or less memory?~~||[https://trac.webkit.org/changeset/49179 49179] [https://trac.webkit.org/changeset/49180 49180] [https://trac.webkit.org/changeset/49181 49181] [https://trac.webkit.org/changeset/49182 49182] [https://trac.webkit.org/changeset/49183 49183] [https://trac.webkit.org/changeset/491865 49185] [https://trac.webkit.org/changeset/49186 49186] [https://trac.webkit.org/changeset/49559 49559]||6.10.2009-14.10.2009|| |
