Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Is Rainbow/FrameBuffer/XXXXFB broken?
Is Rainbow/FrameBuffer/XXXXFB broken? [message #43983] Sun, 07 December 2014 01:54 Go to next message
Mindtraveller is currently offline  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.
Re: Is Rainbow/FrameBuffer/XXXXFB broken? [message #43984 is a reply to message #43983] Sun, 07 December 2014 11:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13428
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).
Re: Is Rainbow/FrameBuffer/XXXXFB broken? [message #43987 is a reply to message #43984] Sun, 07 December 2014 17:08 Go to previous message
Mindtraveller is currently offline  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.
Previous Topic: uld with MingW-w64
Next Topic: Udp class (UdpClient/UdpServer)
Goto Forum:
  


Current Time: Sat Sep 25 08:36:18 CEST 2021

Total time taken to generate the page: 0.01492 seconds