[Webkit-unassigned] [Bug 32461] Adding QPixmap/QImage support for the Qt hybrid layer

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=32461





--- Comment #14 from Noam Rosenthal <noam.rosenthal at nokia.com>  2009-12-23 04:23:57 PST ---
This tries to solve a big performance issue we're tackling.

Sometimes we want a native component to handle heavy lifting of image handling
- either because it's complicated, or because it's the only way. We still,
however, want the images to be displayed and laid out in HTML.
A good example is extracting images from a video that has a proprietary C API
to get those images.

Currently taking those images from the Qt native layer and displaying them in
HTML requires:

- encoding the image in Qt (PNG/BMP)
- sending the image to webkit, either in base64 or in a custom QNetworkReply
- Setting the image source to the base64-encoded string, or to the url that
would trigger the custom network reply.

You might imagine how slow this path is. 

Since QtWebkit uses pixmaps internally, it should be relatively smooth and
trivial to get those pixmaps to the webkit layer. The problem - there's no
current public API to do that! 

This also opens a possibility to offload some of the more complicated rendering
problems to Qt when goings get tough with doing them with HTML, or if the
project has no time to make changes to webkit. For example a slot can send a
few web-element IDs to Qt, Qt would do the heavy rendering, and will return a
QPixmap to the web layer which in turn would decide whether to display it in
the DOM or to draw it using canvas.


So, any current mechanism that would allow me to make an existing QPixmap
available for the web-dev layer, without encoding/decoding/data-copy would work
better than a new one. The problem is that there's no such mechanism :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.