[Webkit-unassigned] [Bug 16885] Official API for raw/GL embedders

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=16885


stephen.clibbery at lateralvisions.co.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stephen.clibbery at lateralvisi
                   |                            |ons.co.uk




------- Comment #15 from stephen.clibbery at lateralvisions.co.uk  2008-02-18 09:47 PDT -------
Hi, We (http://www.lateralvisions.co.uk) are also very interested in a cross
platform web-browser that can be embedded into a 3D world. The suggested API
looks like it would be fantastic for what we need, but I do have a couple more
'dream api' suggestions:

* We use a cross-api graphics layer, so we do not want to be tied to OpenGL.
This is no problem as long as the api gets the raw (system memory) pixel data
rather than an actual gl texture or anything. Looking at the suggestions above,
this is what is being planned anyway.

* It would be nice to be able to deactivate the embedded WebKit: for example,
when it's not visible to the viewer, or just off in the distance, there may be
no real need for it to redraw itself (even if animations/plugins etc are
changing). Further, there would be times when it would be good to deactivate it
fully, so it doesn't even update animations/script/plugins etc (to save CPU
cycles). Don't know how practical this is though.

* It would be useful to be able to request that it draw at a 'different
resolution than the layout is at'. For example, if we normally draw to a
512x512 texture when up close, it would be nice to get it to render the same
content, laid out in exactly the same way, but 'zoomed out' on a 128x128 target
instead of 512x512. This would be useful, for example, when the browser is off
in the distance, and there's no need to spend lots of video memory on a
high-res version of it. It would be inefficient to render to 512x512 then
downsample to 128x128. I guess this might use the same approach as when doing a
full page zoom in a normal web browser.

* It would be great to be able to reroute audio output too (so it can play in a
3D audio system), but I guess most audio in a browser actually comes from
plugins like Flash, so this is probably not practical.


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