Changes between Version 38 and Version 39 of QtBackLog

Dec 10, 2009 2:13:23 AM (13 years ago)



  • QtBackLog

    v38 v39  
    33=== Qt problems ===
    4 ||Description||Branch/Commit||Created on||Landed in||Landed Date||
    5 ||What is left is ARM neon code for the porter duff operations.|| || || ||
    6 ||~~ARM optimized qdrawhelper is only enabled for RCVT (symbian)~~ A pure armv4/C implementation was used giving a significant improvement too. The ARMv4 memfill implementation gave about a 1fps improvement. ||[ memfill] ||9.11.09|| || ||
    7 ||The C version comp_func_SourceOver was improved giving a 10fps improvement on the test case.||[ a69e1] [ 7f379c]||09.11.2009|| || ||
    8 ||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. The first part of ARM detection was done||[ 50b67]||9.11.2009|| || ||
    9 ||Enabled pld (preload) in qdrawhelper for ARMv5te and upwards -- For GNU CC the arm revision is detected automatically and this gave a 1fps improvement.||[ b2d17d]||9.11.2009|| || ||
    10 ||Optimize scrolling of Windowsurfaces. Either optimize memcpy/memmove or consider using a tile based window surface|| || || || ||
    11 ||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]|| || || ||
    12 ||Cut down on usage of QImage::scanLine inside Qt. This was already done in the GIF and PNG decoder.||[ image-changes]|| 19.10.2009|| || ||
    13 ||Make QGifHandler::imageCount scan through the images. This can give a 5% speedup in the image_cycling reduction.|| || || || ||
    14 ||Make picking a QImageIOHandler in QImageReader faster. Currently even the TIFF plugin is asked to handle images.|| || || || ||
    15 ||Consider creating a tile based QImage to allocate image chunks from an image pool with fixed size images|| || || || ||
    16 ||Bring zero-copy to QIODevice... big one. That is good for networking and image decoding.|| || || || ||
    17 ||Consider creating a SharedBuffer that works on tiles/segments|| || || || ||
    18 ||Changes to QHttpNetworkReply to reduce memory reallocations. Reserve some bytes instead of doing ''QByteArray::append'' all them time.|| || || || ||
    19 ||~~Changes to QNetworkReply to remove quadratic runtime in QNetworkReplyHandler and latency fixes~~||[ network-changes] || 19.10.2009|| [ API addition] [ r51411 uses new API] [ Parse Date header directly] [ Remove QByteArray::toLower calls] [ Remove QByteArray::toLower] [ Remove QbyteArray::toLower] ||20.11.2009 ||
    20 ||Cut down on the usage of QUrl::toEncoded as it shows up in the profile of starting jobs.|| || || || ||
    21 ||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 ||The qttracereplay utility should decode a frame at a time to not run out of memory on embedded devices.|| || || || ||
    23 ||The qttracereplac utility should take a -iterations options like known from QBENCHMARK|| || || || ||
     4The QtBackLog was migrated to the JIRA. You can use this []
    258=== QtWebKit problems ===
     10||||Consider creating a SharedBuffer that works on tiles/segments|| || ||
    2711||[ #31849]||Loading of 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. The first issue is that QtWebKit will only schedule four requests per host while Qt networking has a higher limit.||[ r5144 - reduce latency]||||
    2812||||TCmalloc needs to be tested. Does it make anything faster/slower? How to test memory fragmentation.||||||