| 20 | | * Anti talking about tile based rendering. Working prototype using QImage exists, need to get support from Qt to draw to QPixmap from a thread, Discussion if tiling should be supported for everyone or just mobile/QGraphicsView |
| 21 | | * Presentation on how to support JavaScript programmers to see what is going on. Currently something like mozAfterPaint is implemented. This way a JS programmer can record which areas got painted. In the future having a heap profile would be good as well. |
| 22 | | * BenjaminP talking about plans for Qt4.7 to regularily run benchmarks, automate and store results during the development. |
| 23 | | * Talking about OOM handling, checking each allocation vs. just getting killed by the OS vs. getting signals from the OS and then stop loading... |
| 24 | | * Zoltan talks about a valgrind skin called [http://webkit.sed.hu/node/29 freya] to instrument memory usage including showing how much and who was allocating the memory, common call frames can be removed from the trace. |
| | 20 | * Antti is talking about tile based rendering. A working prototype is using QImage to paint in a thread. To make it general usable and accelerate Qt needs to gain the ability to draw to a QPixmap from different threads. One of the limitations will be handling certain CSS attributes that will be ignored just like the iPhone, WebOS and such. It was discussed if tiling should be supported for QWebView and QWebGraphicsView or only for the QWebGraphicsView. We have not drawn a conclusion. |
| | 21 | |
| | 22 | * Presentation on how to support JavaScript programmers to see what is going on. Currently a JavaScript API to expose information about painting is exposed. This API is similiar to the Mozilla mozAfterPaint Event. This way a JavaScript developer can see which content will be redrawn due his code. Another thing is to export the FPS count for drawing to the JavaScript developer. This somehow relates to the WebTime effort of the W3C. In the future we will need a heap profiler that will show the heap usage for each callframe of the JavaScript execution and finally we need the ability to do this on the device and get the data on the host. |
| | 23 | |
| | 24 | * BenjaminP was talking about plans for Qt4.7 to regularily run benchmarks during the development cycle and to automate and store these results. |
| | 25 | |
| | 26 | * We were talking about OOM handling and if we really want to check each allocation vs. just getting killed by the OS vs. getting signals from the OS and then stop loading. The second part was sharing experience about the S60 port and the mainr eason the browser went out of memory. Holger speculated it was due images but from their experience it was mostly due JavaScript code. The conclusion somehow was to either get properly killed from the OS or to get a signal from the allocator/system that will stop loading and is freeing caches. |
| | 27 | |
| | 28 | |
| | 29 | * Zoltan was talking about a new valgrind skin called [http://webkit.sed.hu/node/29 freya] to instrument memory usage including showing how much and who was allocating the memory. The special thing about freya is that it has a powerful configuration file that allows to combine various call frames, or omit certain things that are not interesting. The biggest limitation for him is that freya and the JavaScript JIT refuse to cooperate. |
