0

I have this code:

/* extract single color component from hexadecimal color */
uint8_t ext_col(uint32_t value, int color) {
    return (value >> (color * 8)) & 0xff;
}

glBegin(GL_POINTS);

for (uint16_t y = 0; y < image->height; y+=1) {
    for (uint16_t x = 0; x < image->width; x+=1) {
    uint32_t p = image->data[y * image->width + x]; /* get pixel data */
            
        glColor3ub(
            ext_col(p, 0),  /* red */
            ext_col(p, 1),  /* green */
            ext_col(p, 2)); /* blue */
        glVertex2i(x, y);
    }
}

glEnd();

and it works fine, but just a bit slow, is there anyway to speed this up further, maybe some assembly tricks?

This is the furthest I've optimised it from my previous instance (5x faster), but it still renders a 750x350 image slower than 60 fps.

pinguxx28
  • 17
  • 5
  • 1
    An alternative to optimize the code is to tell the compiler to focus on execution time. Have you tried playing with `-O` options or something similar? (See [this](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html)) – Jardel Lucca Mar 06 '23 at 20:05
  • 1
    Use an array buffer, unless you have to work in immediate mode. – Emanuel P Mar 06 '23 at 20:13
  • 3
    Use a profiler to see where it's spending most of its time. – Barmar Mar 06 '23 at 20:23
  • 1
    I'm not familiar with the `glut` API, but it seems almost inconceivable that there isn't a predefined way to import an array of pixels _en masse_. – 500 - Internal Server Error Mar 06 '23 at 21:13
  • 500 - Internal Server Error has it in one here. Setting a point on screen to be the value for each and every pixel in an image is not the way to go here. A simple suggestion - make a single quad which covers the viewport, texture-map it with the image you have. – enhzflep Mar 07 '23 at 01:46
  • Take a look at Example 8-3 here: https://www.glprogramming.com/red/chapter08.html - In your case, you've obviously already got the image so can forgo the makeCheckImage function. – enhzflep Mar 07 '23 at 02:12

1 Answers1

1

Since ext_col is such a small frequently called function I'd suggest making it inline to get rid of the overhead associated with calling a function. See https://stackoverflow.com/a/145841/7218062. Setting optimization to -O3 will probably do this automatically.

jmq
  • 1,559
  • 9
  • 21
  • This did help a little bit to the point where it sometimes renders under 0.016ms, I guess this is the farthest I will come, and thanks for the help. – pinguxx28 Mar 07 '23 at 06:09