STR #3204

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #3204

Application:FLTK Library
Status:5 - New
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Fl_Shared_Image improvements
Version:1.4-feature
Created By:rokan2
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 rokan2
10:03 Mar 07, 2015
shared_rest.diff
18k
 
 
#2 rokan2
10:04 Mar 07, 2015
Fl_Shared_Image.H
9k
 
 
#3 rokan2
10:05 Mar 07, 2015
Fl_Shared_Image.cxx
40k
 
 
#4 rokan2
10:07 Mar 07, 2015
device.cxx
24k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 rokan2
10:03 Mar 07, 2015
This is reimplementation of Fl_Shared_Image which is ABI compatible but brigs many improvements.

The patch includes replacements for Fl_Shared_Image.H and Fl_Shared_Image.cxx and diff with modifications in all other files.
There is also modified test/device.cxx if you want to try it.

The patch is complete except required changes in OSX Fl_Quartz_Graphics_Driver.

If somebody with Mac experience would modify and submit patch here, it will be complete. The required changes are small:
Fl_Quartz_Graphics_Driver::draw(Fl_RGB_Image *, ...);
Fl_Quartz_Graphics_Driver::draw(Fl_Pixmap *, ...);
Fl_Quartz_Graphics_Driver::draw(Fl_Bitmap *, ...);

In these three functions:
 
- if the function is called during printing, first call Fl_Image::origimal() and then draw this original with additional scaling
- if NOT printing, after drawing, call Fl_*_Image::destroy_data()upon
drawn image (NOT original). Don't worry that you would destroy important data, Fl_Shared_Image engine do all the checks and does not destroy necessary data.

For inspiration see implementations of Fl_GDI_Printer_Graphics_Driver and Fl_PostScript_Graphics_Driver in ps_image.cxx


Improvements and new features:
------------------------------

1) Multiple sequence of copy() does not lose quality because copies are always created from original

2) Printers (or other high-resolution devices) print images with high resolution of the original, not rescaled image

3) Shared image can be resized using resize() method

4) Shared images can be drawn scaled using new function
   fl_draw(Fl_Shared_Image * im, int x, int y, int w=0, int h=0);
This function draws image stretched to (x, y, w, h) rectangle. The function also obeys current transformation matrix.

5) Fl_Shared_Image is now first class citizen with bunch of constructors (including copy constructor) new, delete and assignment operators. Basically it is a small wrapper around a pointer to "true registered image" with proper referencing/dereferencing when passed around,

7) Backward-compatibility get() and find() static functions are equivalent with using new operator, eg following are the same:
  Fl_Shared_Image::get("name");
  new Fl_Shared_Image("name");
No mater how you obtain Fl_Shared_Image (operator new, get() or even copy()) user can use both operator delete and release() function with the same effect
 
8) copy() creates full-features shared image where data is shared with other instances of Fl_Shared_Image


9) User does not need to create a copy before applying desaturate(),inactive() and color_average()operations. Such "color effected" image shares the data with other instances as long as name,  sizes and "resulting color effect" are the same (the table is searched if such an image with that effect already exists, and if not, after creation it registers "effected" image in the table)

10) Possibility of aggressive memory management: if Fl_Shared_Image::assure_data_mode() is set to 0, all image data are created "on demand" only (that is just before first draw) and unnecessary data are deleted (for instance data of resized images are created only to build cache and then instantly deleted: screen devices need only cache for drawing, printers use "unscaled" original).
This also mean that never-drawn images use nearly no memory: for instance if you create image() and deimage() versions for a button but the button was never inactive, the data of inactive version was never created, never desaturate operation applied and the cache never build.

Fl_Shared_Image::assure_data_mode() is ON by default to assure full backward compatibility however for new application it is recommended that it is switched off at the beginning of the program and in rare case that data() of an image needs to be accessed, image->assure_data() should be called prior accessing data image->data() on that particular image.
 
 
#2 AlbrechtS
05:56 Sep 01, 2016
Thanks for the report and the patch(es).

Bumped to 1.4-feature since 1.3 is closed for new features.
 
bottom left image   bottom right image

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

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.