| 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]|| |
