On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote:
> I didn't deep-dive yet into the internals of it, but isn't it that when combining the images at the end, that transfer of the initial images with lots of data basically happens only once? It seems to me devdraw can be quite performant on certain use cases. (UIs with basic shapes)

Thats true. devdraw prepares its images using memdraw and memlayer. After combining those images we get the results on the display.

The moment you do rendering inside your application you have to transfer images using loadimage and flashimage. There is no message inside devdraw which makes it possible to use images from a client process without copying them into the memlayer infrastructure. 

On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote:
> Also I wonder what kind of functions it should be providing.
This intermediate or alternative layer should only add putimage switchbuffers supported by shared memory segments. At least there should be two buffers one foreground and one background buffer directly writeable by the client.

One simple way to realize this would be enhancing devdraw with one single protocol which would render a client side image from shared memory (segments). 

You can quite now create memimages but if you realize the rendering you have to use loadimage and flushimage each time your images change.


devdraw is not slow but it can be made faster with only one extra protocol which is missing. 

Enhancing devdraw this way would also solve the problem but not touching devdraw and offering an intermediate level between the graphics driver and devdraw wouldn't break anything. In the end devdraw also transfers its image to the videocard one way or the other.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mbe750adf3a20ec4a7f7c7b5d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription