Alan Third writes: > On Sat, Nov 30, 2024 at 07:32:10PM +0100, Manuel Giraud wrote: >> Alan Third writes: >> >> > Probably I could do with finding some larger images as the whole thing >> > completes in under a second even without your patch. >> >> FYI, I have used images of 4000 by 3000 pixels. >> >> > I've had a quick dig into lookup_rgb_color and assuming you have a >> > true colour display and there's no gamma calculation going on (I don't >> > know when that happens) it shouldn't be doing a whole lot more. >> > Perhaps it's just the extra over-head of calling a function? >> >> It seems a bit much for just a function call. Or maybe it is the >> init_color_table call? Should it be done for each jpeg_load? > > It's 4000x3000 function calls, so it might have an effect... Yes, you're right. I missed this 😅. > I think it should be done for each load. And I just noticed you need > to add a free_color_table call after you're done with it. Yes, I have re-add it in the attached new version of the patch. I also re-add the ir, ig and ib indices computation. WDYT? > I get that it's a waste of time allocating the table on a true colour > display because it's never going to be used, but it seems to make no > performance difference here and it is still needed on other display > types. Ok, I thought about making this allocation conditional to having a true color display or not... but if you say that there is no performance gain, it might not worth it. > Purely for testing purposes I tried changing the PUT_PIXEL call to > this: > > PUT_PIXEL (ximg, x, y, x_make_truecolor_pixel (FRAME_DISPLAY_INFO(f), r, g, b)); > > I think it might have given an improvement, but it was so slight I > can't say for sure. That obviously can't be used outside of testing, > but it lets us rule out the function call, etc. Yes and the gamma correction part is also missing.