| 32 | | * Holger talks about the QtWebKitPerformanceWork and QtWebKitPerformanceUtilities and how the can be used to measure Qt performance. Comments included limiting the bandwidth used for the fake http server. |
| 33 | | * Shortly discussed the RGB16 approach to save some memory by using color converting RGB32 images to RGB16, specially on symbian a 16bit backingstore exists and painting can be done in 16 bit. [https://bugs.webkit.org/show_bug.cgi?id=29279 #29279] |
| 34 | | * Shortly discussed using WebCore/platform/image-decoders. The downsampling is a feature one would like to use, also the performance appears to be better. We should explore using them [https://bugs.webkit.org/show_bug.cgi?id=32410 #32410]. |
| | 32 | * Holger was talking about the QtWebKitPerformanceWork and QtWebKitPerformanceUtilities and how the can be used to measure Qt performance. The biggest shortcoming is the high variation seen when running the test. E.g. the tst_cycler is running for about 59 seconds on Holger's machine but there can be about a second difference from run to run. QBENCHMARK could and should be extended to provider better information about the variation. One comment was to use bandwidth limitation on the localhost between the http_server and the web browser and check if the numbers get more stable. |
| | 33 | * We shortly discussed the RGB16 approach to save some memory by color converting RGB32 images to RGB16, specially on symbian a 16bit backingstore exists and all the painting can be done in 16 bit. In an older measurement of the page loading tests this could save about 2MB in the peek [https://bugs.webkit.org/show_bug.cgi?id=29279 #29279]. |
| | 34 | * We shortly discussed using WebCore/platform/image-decoders. The downsampling is a feature some of us would like to use, also the performance appears to be better. We should explore using them [https://bugs.webkit.org/show_bug.cgi?id=32410 #32410]. |
