|
|
|
Home » Developing U++ » U++ Developers corner » Rainbow, first iteration
( ) 1 Vote
|
|
| Re: Rainbow, first iteration [message #33284 is a reply to message #33282] |
Fri, 22 July 2011 15:02   |
 |
mirek
Messages: 13975
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  imagine upp running on all the backends..this is a huge advantage.[/quote]
|
|
|
|
| Re: Rainbow, first iteration [message #33357 is a reply to message #33284] |
Wed, 27 July 2011 15:49 |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i'm definitely not into the whole Font's stuff, so i leave it for you but with drawing, i could try helping.
in fact, what is needed, is to at least have a 24 bit support (alpha-less). many current embedded framebuffers offer full 24-bit RGB backend, so firing up dma for the chunk is easy and you got a touchscreen working and a quite nice and responsive GUI.
couldnt the drawing backends be made sort of similar to rainbow? exchangeable? see, internally, upp could still use full RGBA/Color format. but depending of which format you chose for i.e. BufferPainter, a DrawLineOp or the like will call some coresponding helper functions, probably from the rasterizer. and as far as i can imagine, it would only affect the real local buffer painter. all the other painting backends will be connected to native OS means anyway, i.e WIN32 API, X11 drawing, GL rawing, MACOSx drawing. they are not buffer drawing
but i have to admit that i have not enough experience and in-depth knowledge of the whole drawing system, reading code is good, but a view phrases from the devs is best help available..
[Updated on: Wed, 27 July 2011 15:51] Report message to a moderator |
|
|
|
| Re: Rainbow, first iteration [message #33367 is a reply to message #33357] |
Thu, 28 July 2011 17:04 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Wed, 27 July 2011 09:49 |
couldnt the drawing backends be made sort of similar to rainbow? exchangeable? see, internally, upp could still use full RGBA/Color format. but depending of which format you chose for i.e. BufferPainter, a DrawLineOp or the like will call some coresponding helper functions, probably from the rasterizer. and as far as i can imagine, it would only affect the real local buffer painter.
|
Well, I guess something like this is quite possible to do... as in fact, there are only 2 "final" fillers in BufferPainter. Means RGBA is, I believe, only matter of a dozen of virtual functions.
Needless to say, however, that doing so we should also carefully consider refactoring Painter for multithreaded filling.
Another possible option is to write to backbuffer, but somehow remember "monocolor" areas, then render those with "memset" equivalent...
|
|
|
|
| Re: Rainbow, first iteration [message #33626 is a reply to message #32829] |
Thu, 01 September 2011 09:54 |
rett
Messages: 15
Registered: January 2010
|
Promising Member |
|
|
Hello!
I traying compile UWord in rainbow package.
params:
GUI LINUXFB
GCC Optimal
after build a have errors:
----- CtrlLib ( GUI LINUXFB GCC LINUX POSIX ) (1 / 8)
----- RichEdit ( GUI LINUXFB GCC LINUX POSIX ) (2 / 8)
----- PdfDraw ( GUI LINUXFB GCC LINUX POSIX ) (3 / 8)
----- plugin/jpg ( GUI LINUXFB GCC LINUX POSIX ) (4 / 8)
----- LinuxFb ( GUI LINUXFB GCC LINUX POSIX ) (5 / 8)
----- Framebuffer ( GUI LINUXFB GCC LINUX POSIX ) (6 / 8)
----- Painter ( GUI LINUXFB GCC LINUX POSIX ) (7 / 8)
----- UWord ( GUI LINUXFB MAIN GCC LINUX POSIX ) (8 / 8)
Linking...
c++: /home/rett/upp/_out/rainbow/CtrlLib/GCC.Gui.Linuxfb/CtrlLib.a: No such file or directory
c++: /home/rett/upp/_out/rainbow/RichEdit/GCC.Gui.Linuxfb/RichEdit.a: No such file or directory
c++: /home/rett/upp/_out/rainbow/PdfDraw/GCC.Gui.Linuxfb/PdfDraw.a: No such file or directory
c++: /home/rett/upp/_out/rainbow/plugin/jpg/GCC.Gui.Linuxfb/jpg.a: No such file or directory
c++: /home/rett/upp/_out/rainbow/Painter/GCC.Gui.Linuxfb/Painter.a: No such file or directory
There were errors. (0:00.14)
how fix it?
b4b9ef0096f53f85f38f8c84bc5eabec
[Updated on: Thu, 01 September 2011 10:39] Report message to a moderator |
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 20 06:17:15 CEST 2024
Total time taken to generate the page: 0.05499 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
