<Heavily trimmed, as I wish to avoid most of the technical and
non-technical debate and address one point>
On 2018-01-13 12:37 AM, Carsten Haitzler wrote:
On Fri, 12 Jan 2018 19:48:15 +0000 Mike Blumenkrantz
<michael.blumenkra...@gmail.com> said:
On Fri, Jan 12, 2018 at 9:45 AM Carsten Haitzler <ras...@rasterman.com>
wrote:
On Fri, 12 Jan 2018 13:48:46 +0000 Stephen Houston <smhousto...@gmail.com>
said:
Both of these cases are solved by rendering the buffers (both gl and
software) directly in the outer compositor; see
https://phab.enlightenment.org/T6592 on the gadgets workboard for this task
which is already nearing completion.
that doesn't change anything. some work somewhere has to either copy the data
to video memory every change OR the the gpu will likely have to composite and
thus access data over a bus (eg over pci bus). if it's an embedded system all
memory is equal, but subsurface are going to unlikely help because you'll not
have enough hw layers to assign to a host of gadgets. there will generally
maybe be 2-5 ... maybe on a good day 8 or 10 layers, and these are far better
used for application windows (e.g. separating desktop, active/focused window or
window being moved/dragged, etc. etc.). it's still a gadget rendering to a
buffer THEN that buffer having to be copied again ... always. at all times.
Hey Raster,
The trick here is that a wl_shm or dmabuf will never actually be
rendered by the *nested* compositor.
The nested compositor will simply created a proxy buffer and use the
existing "hardware" plane infrastructure to place this on a subsurface
(I'm calling these virtual hardware planes). It won't even open the
file descriptors, it'll just create parent compositor objects for them
and proxy along placement and damage requests.
There are a few technical hurdles and @optimizations required to get us
there, but that's the tl;dr.
When finished, this should prevent all "double draw" performance losses
as well as allowing some surprising tricks like GL clients proxying
dmabuf GPU rendered buffers through a SW rendering nested compositor to
a GL rendering parent compositor, which can directly use them as textures.
Thanks,
Derek
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
