From: Scott F. <sc...@st...> - 2009-05-19 12:38:13
|
On Tue, May 19, 2009 at 5:57 AM, Michael Reinelt <mi...@re...>wrote: > Hi Scott, > > > I decided to work on this. > Great! Histograms have been on my todo list for years, but as I'm that busy > all the time... > > > I think I'm understanding the bars code. The > > one thing that confuses me is pack_segments. I found that it cleaned up > > a lot of garbage however, so I'm assuming that's all it's for. > > Well, as I said, the bar code is quite complex. I'll try to explain it a > bit: > > A bar (especially the split bars) are made of custom chars (except the > "empty" and the "full" cell, empty is always a > blank, full is used only if a solid block is avaliable. > > So if you have several bars (with mixed directions) and split bars > alltogether at the same time, you'll need a very lot > of these custom chars. Unfortunately, the number of custom chars is limited > (usually only eight). So the bar code tries > to add little "errors" to the bars to combine two chars into one (think of > two bar cells, one with three pixel rows set, > one with two. The bar code would either expand one bar to use three columns > or reduce the other cell to use only two > rows. This "compaction" is quite complicated, because there are several > constrains you have to deal with: a bar line > shall never be "interrupted" (it should not contain "holes", this is > especially tricky with split bars), you should not > redefine a custom char that is currently visible (otherwise you'll get some > flickering) and so on. The split bars are great. I thought that was one of the cooler things about LCD4Linux. > > > > I only > > dealt with direction east in the character creation because only east > > works for me. Outside of west maybe, It might be a limitation with my > > CFA635. > No, there shouldn't be a limitation. bars should work in all directions, > otherwise there may be a bug. > > > I'm ordering a picoLCD here soon so I'll have a graphics display > > to play with and I can work on a graphics version of the histogram, > > unless someone else picks it up. Anyhow, there's a diff attached. > > graphic histograms would be great, too! > > > > Why don't westbound bars work? > see above > > > I don't really understand your patch. You tried to reuse the bar code, but: > > - a histogram should not deal with "val1" and "val2", this is for split > bars only (at least there shouldn't be a > seperate expression) Well, it was an experiment. I wanted to make it complicated I guess. That part in define_chars is broken. That's what I was working on when I took a break to check email. Anyhow, I envisioned a left and right half per each character cell. Not a good idea? Dealing with 2 values makes more sense on a graphical LCD with color settings. > > > - you can specify the length of a histogram (as with bars), but shouldn't > there be something like a "width"? Looks like > you're always using the whole size of the display..... What would be the difference between width and length? When I setup a histogram with length of 5, the histogram stays within those limits, and I can place a widget after it. I used this length in adjusting bar cells. One cell is discarded each pulse. I may have missed parts where an index may fall out of range, but it shouldn't be using the whole screen. If it is, point me to the code and I'll figure something out. > > > > bye, Michael > > > -- > Michael Reinelt <mi...@re...> > http://home.pages.at/reinelt > GPG-Key <http://home.pages.at/reinelt%0AGPG-Key> 0xDF13BA50 > ICQ #288386781 > |