2011/3/6 mattschinkel <[email protected]> > > OK, we have a conflicting API regarding lcd_write_pixel. Depending on > GLCD, > > last parameter is either a color or a mode (on|off|xor) > > What is xor? clear? A "clear" color should not be implemented by > glcd_common, it should be implemented by glcd_write_pixel() which is > in the glcd device library. If the color "clear", then don't write a > pixel. >
XOR means if pixel is on, then turn it off, if it's off, turn it on. > > > Colors should be handled outside procedure parameters, defining pen & bg > > color *before* calling plotting procedures. I think this is what we > agreed, > > right ? If so glcd_common should be updated accordingly. > > I agree, I just never got around to changing this. > OK. > > On the other side, since "mode" is part of lcd_write_pixel signature, all > > plotting procs (line, box, ellipse, ...) should take a "mode" parameter > to > > specify whether we want to make pixels on, off or xor. I'm not in favor > of > > putting this parameter outside lcd_write_pixel signature as pen color for > > instance, because "mode" is very tied to one pixel, whereas pen color > looks > > like more a global LCD option. > > ON and OFF are colors for you so why have this mode perimeter when you > can just choose your pen and background colors accordingly? It also > does not seem useful on color GLCDs. I think what you are really > asking for is inverted colors. Inverted colors could be taken care of > by the glcd device lib. > "color" and "mode are indeed quite close together for a B&W GLCD but not completely. "mode" also makes sense for color GLCD. Say your pen color is red, background yellow: - mode on: plot a red pixel - mode off: unplot red pixel, means plot a yellow pixel (background) - mode xor: if pixel is yellow, plot red, if red, plot yellow > > So, I suppose if you want this implemented your glcd device library > could have a variable or constant to set inverted / non-inverted. > Already handled with background and pen colors > > > I tried to use glcd_common's lcd_line(), but no success though... > Did you get anything on your screen? Maybe output the > currentx,currenty values to the serial port where you see > lcd_write_pixel in the line proc. We can probably plot it by hand or > use excel. Maybe you can send me this data? > Finally got it working as I mentioned. I wasn't calling lcd_clear_cache() > > Did you find a good way to turn on and off the cache? (this is what > the old glcd cache code was for). No, for now, it's mandatory, but I'll surely make it optional. Performance seems to be quite nice, paticularly since using waterwark regions (lib keeps track about minimum region in the cache that has been changed and should be considered during next refreh. This way, not all the cache is processed). > Should this cache be available for > other GLCDs? > Maybe, maybe not :) I'm not sure yet if this can be generic without huge overhead. To be investigated, I'll keep this in mind. Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
