nanogui: Frame buffer Interface
Subject:
Re: Frame buffer Interface
From:
Michael Emmel ####@####.####
Date:
8 Feb 2000 21:43:48 -0000
Message-Id: <38A08B51.E9826AA9@cyrusintersoft.com>
Erwin Rol wrote:
> Hello All,
>
> Went without mail from like a few hours so here one to keep
> yer inbozx busy :-)
>
> First i have been breaking my head to think of a way to update
> slow LCD dot matrix displays. They have a 8 bit bus with some chip
> selects,
> you first write the address of the memory byte in "video" ram and than
> the
> actual byte for that place. This means updating the whole display from
> CPU ram is to expencive when probably less than 10 % is changed after
> some
> dots drawwing. So a virtual RAM framebuffer (i first thought) would be
> not possible. But now i came up with the following.
>
> Create a RAM frame buffer and write to it.
> There is running a update thread (or one cals the flush() function
> manualy)
> that compares the ram buffer with a second ram buffer , the bytes that
> are different
> and written to the LCD, and copied to the second ram buffer. That way
> one knows what is changed between two flush() calls. thinking about
> display sizes
> of for example 128 * 64 dots the video memory would be 1024 bytes.
> scanning trough
> that and comparing them will in my idea be cheaper than to write all
> those
> bytes to the actual LCD. The same for text displays they are even
> smaller 20*4 (80 bytes) times 2 would be no problem and only the chars
> that changed between the flushes
> will be updated, this will probably increase the update speed of the
> display to and should not lay much below the direct update from source
> code. It can even combine (in the graphics display) writes to the same
> byte.
> Anybody something to add or say about that ?
This sounds suspicioulsy like what VNC does maybe you can use there code.
I'd love to here about some speed tests on this
Mike
