Has there been any thought of a drawPoly() function?

[rickwendy]

Any chance of implementing a drawPoly type function for drawing graphs without a hundred drawLine calls? Usually this would include a bool closed flag to indicate a closed polygon vs a line.

[olikraus]

I assume it wouldn't be that complicated to create some custom function for this.

int sx,sy;
int lx, ly;

void moveTo(x, y) {
  sx =x, sy= y;
  lx =x, ly= y;
}
void lineTo(x, y) {
  drawLine(lx,ly,x,y); lx =x, ly= y;
}
void closeLine(void) {
  drawLine(lx,ly,sx,sy); 
}

[rickwendy]

Thanks for your response. Yes, of course, I've already done that. I'm concerned with CPU time with all the calls to drawLine, checking bounds each time etc. My real time application is polling a lot of sensors and devices while updating the graph each graph time. If this was done at a lower level in the u8g2 code it would perhaps cut the CPU usage by 80% for a drawPoly vs 100 drawLine calls. Most graphics libs support a drawPoly type function for exactly this reason. I'm an old time graphics programmer, first started with an 8086 based PC in 1982 writing the first seismic data processing system for the PC, where line drawing of seismic signals was very intense for such a primitive CPU. Anything we could do to save cycles - including assembly coding some portions to write to the graphics card.

[rickwendy]

I guess another way of saying it is that code brevity, or highly layered code, while making for more compact and beautiful looking source code, is seldom the most CPU efficient. Each call to a function causes a stack push/pop of all the CPU registers. A single function performing the graphics primitives in a loop is hugely more efficient.

[olikraus]

hehe, same here, starting with C64 and 8086 assembly language. But u8g2 is mainly a lib to make some hardware work. All the abstraction layers in u8g2 will certainly slow down the rendering. I think u8g2 is more a starting point rather than a high speed rendering engine. I also had the memory restriction on 8 bit AVR architecture in mind, when designing u8g2. So indeed code density was more important then speed.

There are some macros u8g2.h which could be disabled to improve speed, for example this:

u8g2/csrc/u8g2.h

Line 108 in 8430f65

#define U8G2_WITH_INTERSECTION

You could also write directly to the bitmap via the direct access api:
https://github.com/olikraus/u8g2/wiki/u8g2reference#direct-access-buffer-api

There is also the option to keep some data on the display and only draw delta changes.
By default u8g2 will clear all the data and the the user has to fill the new data. However this can be disabled:
https://github.com/olikraus/u8g2/wiki/u8g2reference#setautopageclear

So the time consuming deletion can be avoided, but the u8g2 user is responsible to clear the data.

For each of the options, there should be also corresponding examples. But of course you can also ask here.

All in all, if you look for max speed, then other methods might be more promising than a drawPoly function.

[rickwendy]

Thanks for the suggestions. Wow, C64, that brings back memories. And the Tandy TRS80 and Sinclair too! I remember farting with those in Basic and thinking the “future was here”. Haha, and now a little Arduino nano can blow the doors of any of those.

I’ll look into your suggestions. It’s not a huge deal, I can make it plenty fast enough the way it is. I really love the simplicity and versatility of u8g2. Keeps the graphics overhead down and lets me add some highly beneficial analytic graphics to my control systems using nothing more than a nano.

Among other things, I’m currently building a variable speed pump driver for my boats fresh water system. Having some simple graphs to help tune the PID control parameters is fantastic. Also building a reverse osmosis creep reduction controller and graphs are again useful. Thanks so much for this library.

I’m a retired electrical engineer and I now spend most of my time building embedded systems to enhance my boats existing systems.

[olikraus]

Nice, yeah, still some years to go until my own retirement. That's also a drawback here. I don't have much time to work on u8g2 :-/