On 06.02.2018 13:32, finnbry...@gmail.com wrote:
> This is a clearly solvable problem (browsers do it internally)
but isn't necessarily simple, some obvious solutions:
- a way to get the texture directly on the gpu, to avoid copying back to the cpu
(likely platform and api specific, if the embedder is using a different graphics
api, or none, this can be annoying to work with)
On X11 you can stack windows of different clients (even from different
hosts) into each other. The window manager does the reparenting (which
it also uses for window decorations, etc). IMHO, Windows has similar
techniques (also used for out-of-process OLE/Active-X components).
When using DRI, the clients render into their own buffers and let the
Xserver do the composition (via GPU).
Wayland even goes further: applications always directly render into
their own buffers/surfaces (via gpu), and the compositor puts them
together to the output device (which even could be a hw video codec
for streaming, etc).
I'd like to convince you that focusing on the "minimal-effort" option would > be a mistake - non-performant browser embedding is unacceptable for
many use-cases,
Minimal doesn't need to be slow. The main problem here is a convenient
way for setting up the embedding, which depends on the underlying window
system. Several widget toolkits, eg. Gtk, already have widgets for that
(eg. using Xembed protocol on X11). That's only a startup task.
Anything else should be pretty low traffic (call some URL, status
notifications, etc). 9P seems to be a fine interface for that.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
