I've been thinking about algorithms to optimize what's sent over the serial while not paying attention in lectures.. On the K610A your options are somewhat limited by the command set; The 3000 and 7000-series have more tools available.
To figure out what's changed, you XOR the previous frame with the current one.
The simplest thing to do is just figure out the bounding rectangle of what's changed and draw just that as a bitmap:
Changed = OldFrame XOR NewFrame
Left = 128, Right = 0, Top = 32, Bottom = 0
NumChanged = 0
for ( y = 1 .. 32) {
for ( x = 1 .. 128 ) {
if ( Changed[x][y] == 1 ) { //Changed would be a 1 dimensional array, but for simplicity..
NumChanged++
if ( x < Left ) Left = x
if ( x > Right ) Right = x
if ( y < Top ) Top = y
if ( y > Bottom) Bottom = y
}
}
}
if (Right >= Left && Bottom >= Top)
draw(NewFrame,Left,Top,Right-Left+1,Bottom-Top+1) // bitmap, starting_x, starting_y, width, height
This works well when small areas of the screen change, but if only the top-left and bottom-right pixels change you end up drawing all 128x32 of them when only 2 needed to be. So you could split the screen up into smaller rectangles and do the cropping/drawing thing on each one individually at small overhead (a few extra bytes per draw) and potential large gain.
You could also calculate for each update rectangle whether it would be less bytes to just move the cursor and set/clear each of the changed pixels. If it took say 9 bytes to move the cursor and update one pixel, and a bitmap draw took 7+data bytes, then you'd want to draw by pixel if 9*NumChanged < 7+(Bottom-Top+1)*(Right-Left+1)/8.
If you want to get more complex, you could look at the change and try to identify the optimal configuration of rectangles to draw, or rectangles of solid image that you can draw with an area/box fill for only a few bytes. This is where peeking at VNC code to figure out how they figure out what the update rectangles should be.. no efficient algorithm comes to mind immediately.
On the 3000 and 7000-series displays with more advanced software in them you can come up with all kinds of tricks using scrolling ability and other cool features they have. The K610A doesn't support XOR-mode drawing, so you have to send the actual pixel values instead of "change these pixels". With XOR drawing you could use the line/box/etc drawing routines to toggle large groups of pixels at a time for virtually no serial transfer (5-10 bytes to issue a draw this from x1,y1 to x2,y2). This stuff might be particularly important if you're using the 256x64 3190 model, which has a lame 38,400 connection to update 4x the pixels. The 140x32 7000-series one is 115,200bps so you can get almost 30fps just blindly blitting the whole screen every frame.
Previous Topic
Index