U++ framework: U++ Developers corner » Is Rainbow/FrameBuffer/XXXXFB broken?

Home » Developing U++ » U++ Developers corner » Is Rainbow/FrameBuffer/XXXXFB broken?

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

Is Rainbow/FrameBuffer/XXXXFB broken? [message #43983]

Sun, 07 December 2014 01:54

Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.

Experienced Contributor

Recently I've made an attempt to look Rainbows-based and WinFB examples, but they failed to compile.
reference/UWord_FB seems to be broken too.
Is it some kind of upgrade going on? Or framebuffer-based stuff is completely broken in latest revisions?

By the way, I consider making framebuffer-like front-end for e-ink displays. It's 4 bits per pixel and needs manual updates of display. How do you think, will it be possible to implement it without changing any of Ctrl or any other U++ internals?
Thanks.

Report message to a moderator

Re: Is Rainbow/FrameBuffer/XXXXFB broken? [message #43984 is a reply to message #43983]

Sun, 07 December 2014 11:02

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

Mindtraveller wrote on Sun, 07 December 2014 01:54

Recently I've made an attempt to look Rainbows-based and WinFB examples, but they failed to compile.
reference/UWord_FB seems to be broken too.
Is it some kind of upgrade going on? Or framebuffer-based stuff is completely broken in latest revisions?

By the way, I consider making framebuffer-like front-end for e-ink displays. It's 4 bits per pixel and needs manual updates of display. How do you think, will it be possible to implement it without changing any of Ctrl or any other U++ internals?
Thanks.

Yes, it might be broken now. There were changes in CtrlCore; so far I have only fixed "canonical" backends. But should be easy to fix (might do it soon).

e-ink: definitely possible. But I would say that due to manual updates, your GUI will have to be changed a bit anyway....

In any case, I would probably start by thinking about some screen buffer (with all pixels) in application and some mechanism how to put that data to e-ink.

4-bits is not a problem at all, just make convert RGBA to monochorome... (maybe you might want some dithering too).

Report message to a moderator

Re: Is Rainbow/FrameBuffer/XXXXFB broken? [message #43987 is a reply to message #43984]

Sun, 07 December 2014 17:08

Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.

Experienced Contributor

Quote:

e-ink: definitely possible. But I would say that due to manual updates, your GUI will have to be changed a bit anyway....
In any case, I would probably start by thinking about some screen buffer (with all pixels) in application and some mechanism how to put that data to e-ink.

Due to the nature of e-ink display, the most tricky part of frame-buffer functionality is partial updates. Very much like you use in Turtle where (I suppose) you update only the refreshed Ctrl pixels. It will be great if it will be possible to use partial updates mechanism from Turtle to optimize rendering speed.
Talking about dithering, yes on-the-fly conversion to 4bpp is not the best option in the sense of efficiency and memory consumption (the code will be executed on ARM CPUs). But it may be the only option which keeps U++ internals intact.

Report message to a moderator

Previous Topic:	uld with MingW-w64
Next Topic:	Udp class (UdpClient/UdpServer)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Apr 25 22:40:17 GMT+2 2026

Total time taken to generate the page: 0.00470 seconds