So... It's about time that I get around to libgfx.so. Mainly, the buffer part. I am looking at not reinventing the wheel with buffer copying routines, etc.. Firstly, I am looking at using the Ion routines for copying a buffer to the LCD.

How is the memory laid out? Is each byte a new col, or a new row? Does it use the LCD memory not shown?

Also, I have some serious questions on how to implement greyscale... I know that 2 buffers are used, light and dark. Is this the order that they are shown?

Code:


Also, what is the frequency that they flip? I can use any time calling any function that I want as GlassOS is fun that way (no silly im 2).

Lastly, does anyone know of a fastCopy routine that would mask these 2 buffers? (Just incase my code isn't as fast as others)

I have looked at other greyscale libraries, but they didn't explain too much on the process/specifics...

each byte is a part of a row in the graph buffer's layout, however, based on how you code it, it could be part of a column though the usual way is to treat it as rows, it requires less setup.

Basically, how it works is by taking two buffers, and (almost) simultaneously applying a AND'ed dithering pattern that applies one to the first buffer (let's say for the front buffer in 4 level gray, %11011011) and then push that, do the same thing to the other buffer (backbuffer, %00100100 pattern) pop to something like BC, OR the two together, and then output that byte to the the LCD. Repeat 767 times

It actually isn't as hard as it seems, but some concepts -- such as perfectly aligning the pattern to the LCD's refresh rate to eliminate flicker -- isn't nearly as easy and I would ask an expert on the matter such as thepenguin77 for advice on how he did that.

Why use a dithering pattern? Unless it involves some dirty work with the LCD...

Its purpose is to make it look nicer.
If you don't mind writing a program, contrast flashing between an all-black and an all-white screen and flashing between two complementary checker-board patterns.
It looks a whole lot better the latter way

:-\ Unfortunately, I can't run GlassOS on a real calc yet (as the fs isn't done), but I would assume that dithering would take more CPU time to plot it to the screen and cause flickering... Unless you are saying not to dither pixels, but actual squares, which makes sense so you don't get a scan-line effect...

no, actual dithering is usually the best way to go. It's a few thousand cycles more per copy to the LCD's RAM, but you can embed it into your buffer-copying routine without much speed effect Actual squares wouldn't make a scanline effect, but a rather-more-painful-to-look-at cloudline of weird squares. since the smaller the scan pattern you go the less noticeable, pixel dithering is considered the best way to achieve this.

I have greyscale, sorta. It only uses ioFastCopy and has no dithering yet. I don't have time right now for that, but I will soon. It currently flickers, but it draws.