Changes between Version 14 and Version 15 of QtBackLog


Ignore:
Timestamp:
Oct 18, 2009 11:46:17 PM (11 years ago)
Author:
zecke@selfish.org
Comment:

Move QtWebKit problems into a table.

Legend:

Unmodified
Added
Removed
Modified
  • QtBackLog

    v14 v15  
    1717
    1818=== QtWebKit problems ===
    19  * 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.
    20 
    21  * TCmalloc needs to be tested. Does it make anything faster/slower? How to test memory fragmentation.
    22 
    23  * 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.
    24 
    25  * 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. The bug report is [https://bugs.webkit.org/show_bug.cgi?id=30211 here]
    26 
    27  * Loading speed [https://bugs.webkit.org/show_bug.cgi?id=30293 regression]
    28 
    29  * Loading bug/API bug on loading amazon in QtEmbedded Linux. [https://bugs.webkit.org/show_bug.cgi?id=30301 #30301]
    30 
    31  * 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.
    32 
    33  * Using QImageReader::setQuality(49) will use JDCT_IFAST and promises to give a 5% speedup on image_cycling.
    34 
    35  * ~~Image decoder changes needs to be measured. Do they make anything faster/slower? Do they consume more or less memory?~~ Landed in [https://trac.webkit.org/changeset/49179 49179ff]
     19||Bug||Description||Commit||
     20||||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.||||
     21||||TCmalloc needs to be tested. Does it make anything faster/slower? How to test memory fragmentation.||||
     22||||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.||||
     23||[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.||||
     24||[https://bugs.webkit.org/show_bug.cgi?id=30293 #30293]||Loading speed regressed due image changes?||||
     25||[https://bugs.webkit.org/show_bug.cgi?id=30301 #30301]||Loading bug/API bug on loading amazon in QtEmbedded Linux. Loading does not complete.||||
     26||||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.||||
     27||||Using QImageReader::setQuality(49) will use JDCT_IFAST and promises to give a 5% speedup on image_cycling.||||
     28||||~~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 49179ff]||