[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #3313

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  chris 21:36 Jun 08, 2016	fl_read_image.diff 2k
	#2  chris 09:08 May 18, 2017	fl_read_image_speedup.diff 3k
	#3  chris 09:09 May 18, 2017	image_surface_read_image_speed.cxx 3k
	#4  chris 05:10 Feb 16, 2018	fl_read_image_speedup_v2.diff 3k

Trouble Report Comments:

	Name/Time/Date	Text
	#1  chris 21:36 Jun 08, 2016	Reading large images with fl_read_image() e.g. via Fl_Image_Surface()->image() can be pretty slow. I took a closer look at the implementation and it consist of two parts: - reading the image from screen with XGetImage() - converting this image to an FLTK RGB-Image I don't know if the reading part can be improved on, but the second part is overly complex and contributes a lot to the total time. It deals with many formats XGetImage() can return, but nowadays the chance is high that it always returns a 32 bit RGB image. Separating out this case reduces the copying effort to the bare minimum and speeds it up by about 10x! As an example: Reading an average complex image (because XGetImage() seems to be cached/optimized and does not scale linear with image size, but depends on the content too!) with W x H of 20000 x 1000 pixel took about 500ms before and 280ms after. From this 250ms come from XGetImage(), so the conversion time reduced from 250ms to 30 ms. I attach a patch that is just for illustrating the idea. It deliberately does not deal with alpha case (because it is normally not used) in order to get the maximum possible speed gain.
	#2  chris 06:12 Nov 02, 2016	Bringing this one up, as there are changes for rc4 anyway: Would it be worth to include in next release? Speed is something important in F(AST)LTK. And in this particular area it is hard to intercept in user code.
	#3  AlbrechtS 11:47 Nov 02, 2016	Yep, this will be considered for the next release after 1.3.4, which supposedly will be 1.4.0. The 1.3.x series is closed for new features, sorry. All STR's for 1.3.x will be considered for 1.4.x if possible. Note: so far 1.4.x is and will likely stay API compatible with 1.3.x (with a few exceptions of deprecated functions in 1.3.x that might be removed in 1.4.0). No guarantees though.
	#4  chris 09:08 May 18, 2017	I have updated the patch for FLTK 1.4 rev. 12239 with attached file fl_read_image_speedup.diff. The patch currently also includes time measurment lines. I also attach a test program 'image_surface_read_image_speed.cxx' to exercise fl_read_image() calls with large images. This are typical outputs of the test program on my machine: Original (non-optimized) code: ------------------------------ First call Fl_Image_Surface::image() get XImage (20000x1200): 300 ms copy XImage (20000x1200): 298 ms Second call Fl_Image_Surface::image() get XImage (20000x1200): 72 ms copy XImage (20000x1200): 298 ms Time Fl_Image_Surface::image(): 370 ms Patched (optimized) code: ------------------------- First call Fl_Image_Surface::image() get XImage (20000x1200): 305 ms copy XImage (20000x1200): 36 ms Second call Fl_Image_Surface::image() get XImage (20000x1200): 72 ms copy XImage (20000x1200): 35 ms Time Fl_Image_Surface::image(): 108 ms The relevant lines for this patch are the 'copy XImage' times: One can see that they drop from ~300ms to ~35ms with the patch. Not sure if that is really the fastest method, parhaps a few ms can be improved with other ways of coding. So take the patch as outline.
	#5  greg.ercolano 15:22 Oct 28, 2017	Bumping this STR for consideration, as we're now in dev for 1.4.0
	#6  greg.ercolano 15:24 Oct 28, 2017	Changed:     Subsystem: (unspecified) -> Image Support     Software Version: 1.3-feature -> 1.4-feature
	#7  chris 05:12 Feb 16, 2018	Updating the patch, because it did not work after revison #12653, which removed the 'alpha' parameter from the method Fl_X11_Screen_Driver::read_win_rectangle().

[ Return to Bugs & Features | Post Text | Post File ]