U++ forum: Welcome to the forum

Re: Rainbow, first iteration [message #33284 is a reply to message #33282]

Fri, 22 July 2011 15:02

mirek
Messages: 13976
Registered: November 2005

Ultimate Member

kohait00 wrote on Fri, 22 July 2011 08:17

@mirek:

I am experimenting with a ImageBuffer hack (including Buffer<>) to pass the fb surface directly as underlaying for Ctrl::framebuffer. the speed improvements for win/linux, fb0/SDL are considerable. especially in terms of responsiveness of the input handling.
while video handling under pc systems wont see much advantage, direct handling in embedded will really profit.

maybe we should really think about making upp directly drawable on fb surface, and making double buffering optional..

I am definitely NOT opposed to the idea; but let us say it is the 'next level'.

I also see two related issues there - first I believe ImageBuffer and Painter should have some way how to directly paint on external buffer. This part is relatively simple.

Then, completly different issue is Framebuffer with direct draw support - some things have to be significantly different there and more complicated (e.g. to have mouse cursor that is not flickering is a little bit harder without backbuffer).

OTOH, while the first part (Buffer/Painter) has to be implemented in canonical packages by core developers, new Framebuffer could be developed now by anybody and in fact, it does NOT have to relly on ImageBuffer changes - it is not written in the stone that you have to use Painter...

That said, I also see big oportunity in DrawText optimization. Current Painter implementation is "pendantic" and always expects you want to do something different with each glyph than to fill it. Thus when doing DrawText, everything is rendered as quadratic curves and then filled. I think that some sort of bitmap caching for DrawText could bring dramatic improvement in FB gui responsivnes. If I ever get to it, this will be the first thing I will try to improve....

Mirek

i will provide a patch to test it for your self. it is really quick.

@unodogs: consider using WinAlt, in comparison with Skeleton, to see what exactly is needed. framebuffer is really a good choice as well, if irrlicht can offer a direct surface to draw to..fb based would not profit from optimized draw operations of irrlich though. see progress of MacOS port..it's getting exciting Smile

imagine upp running on all the backends..this is a huge advantage.[/quote]

Report message to a moderator