DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2637 Version: 1.3.0 To me it looks like it is the consequence of doing two pixels in each iteration. Take a look at the "innards" #defines in fl_draw_image.cxx. There seems to be some effort there to do two pixels at a time when U64 is defined. What if the image width is odd? I don't think this gives much performance gain anyway. Consider 3 byte size reads, some shifts, one 32 bit write versus 6 byte size reads, more shifts, and one 64 bit write (which may not even be 64 bit on a 32 bit architecture that has U64 defined). Why anyone even bothered is beyond me... Maybe that whole U64 dependent conditional part branch just be deactivated, and then re-checked with Valgrind. I'll take a look at it. Link: http://www.fltk.org/str.php?L2637 Version: 1.3.0 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
