[webkit-qt] Extending the hybrid support of QtWebkit to more types: feedback please!

[Simon Hausmann]

On Sunday 13 December 2009 Rosenthal Noam (Nokia-D-Qt/RedwoodCity), wrote:
> >-----Original Message-----
> >From: webkit-qt-bounces at lists.webkit.org
> >[mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of
> >Hausmann Simon (Nokia-D-Qt/Oslo)
> >
> >Ideally we can find a solution that we can implement now but
> >that we know _will_ be compatible with #31863.
> 
> How about the following alternative:
> 
> Instead of creating an HTMLImageElement implicitly, we create an
>  intermediary element that can explicitly create an HTMLImageElement, or be
>  encoded into a data URL. A Javascript app using it would look something
>  like:
> 
> 	var pxm = myQObject.someQPixmapProperty;
> 
> 	var img = pxm.createImageElement();
> 		// or
> 	someOtherImg.style.backgroundImage = "url("+ pxm.toDataURL("image/jpeg")+
>  ")";
> 
> 	So it's basically a custom JS object that looks like:
> 	{
> 		width: ...,
> 		height: ...,
> 		createImageElement: function() {...},
> 		toDataUrl: function(mimeType) {...}
> 	}
> 
> Is this a workable approach?

That looks much better :-), makes it much more explicit what's happening.

> I'm not really particular about the implementation detail myself... Any way
>  that would allow me to transport pixmaps between Qt and webkit without
>  having to encode/decode/memcpy them would work :) I'm willing to implement
>  this API myself, or any other alternative, if we agree that they're the
>  right one and are a good candidate to go upstream in a timely manner.
> 
> >On second thought I _think_ the resulting API should not be a
> >direct conversion from QImage/QPixmap to HTMLImageElement, as
> >they are not equivalent. The latter has a lot more attributes
> >to specific that are not part of QPixmap/QImage.
> 
> That's what I was thinking, but apparently there's no image object
>  accessible to Javascript except HTMLImageElement. Even when you create an
>  image in javascript (var img = new Image()) and draw it in canvas, you end
>  up with an implicit HTMLImageElement... This is perhaps a deficiency in
>  webkit but I don't think we can fix it in the hybrid layer.
> 
> Does the proposed alternative above look more like how we'd end up doing it
>  with QtScript style APIs? It will require more work for sending pixmaps
>  from webkit to Qt, but that's actually not as important.

Yeah, it sounds like something that would be possible to implement.

Hmm, the next question for me is then: What's the most convenient API to offer 
to the C++ developer?

In the grand scheme of things this is a feature that is not only interesting 
for QtWebKit, it's a problem that exists for example also with QLabel or 
QTextBrowser for example: The developer has some generated content in the form 
of a QPixmap and would like to use it in QtWebKit.

For _that_ the common denominator is a uri. If there was a way to bind a 
QPixmap to QtWebKit (either a QWebPage, a QWebFrame or maybe a 
QNetworkAccessManager instance?) and you'd get a uri for it, then there would 
be no need to extend the JS bindings or anything else. It could be used 
anywhere you can specify images.

Just prototyping:

        QVariant data = myPixmap;
	QUri url = webPage->networkAccessManager()->addResource(data); // mime-type 
is implied by QVariant type

	QWebElement img = ...;
	img.setAttribute("src", url.toEncoded());


In the implementation I think we might be able to take the necessary shortcuts 
so that we can avoid that the pixmap is serialized all over the place. But at 
least this way the ownership is clear.


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20091229/29a6968f/attachment.bin>