Thoughts for a redesign of Fl_Shared_Image.
IMHO the biggest problem with Fl_Shared_Images is that you are
forced to use a static Fl_Shared_Image::get() method to create
a shared image, and that you _must_ use release() to delete it.
Also, as discussed today in fltk.developement, I think that the API
for Fl_Shared_Image would be much easier to handle, especially if
you use the base class pointer, including "delete img", where
img is a (Fl_Image *) pointer that actually points to a
Fl_Shared_Image object.
The following is only a working paper, not a full specification, and
of course there's no real implementation yet.
(1) What to achieve:
The new Fl_Shared_Image...
(a) shall have the same interface as before (API compatibility)
(b) shall have public constructors (one or more)
(c) shall have a public destructor (no release() method)
(d) shall not have static methods, if possible, but ...
(e) shall keep well-known methods (as deprecated methods)
(f) shall not expose the refcount() method
(g) shall allow static and local instances
Although some of the points seem to contradict, it is only a matter
of additional (then deprecated) methods to keep for a while.
(2) How to do it:
Split Fl_Shared_Image in two classes, one "public" class (the new
Fl_Shared_Image), and one "helper" class for management of the
internal data (image array, as before).
(3) Implementation:
The new helper class (let's call it Fl_Shared_Image_intern) does
all the management work that Fl_Shared_Image did before.
The new Fl_Shared_Image constructor calls Fl_Shared_Image_intern::get()
and keeps a protected pointer to its Fl_Shared_Image_intern instance.
The destructor calls Fl_Shared_Image_intern::release() for its internal
image pointer.
(4) Refcounting:
Since the Fl_Shared_Image constructors and destructor call the necessary
get() and release() methods, there is no need for the user to call
get() or release() or access the refcount. Simply deleting the
Fl_Shared_Image object calls the internal release() method, and this
deletes the internal Fl_Shared_Image_intern object, if the refcount is 0.
(5) Deprecated methods (examples only):
Fl_Shared_Image::get(const char *name, int W = 0, int H = 0) {
return new Fl_Shared_Image(name,W,H);
}
Fl_Shared_Image::release() { delete this; }
(6) Advantages:
The new Fl_Shared_Image objects can be handled like all other Fl_*_Image
objects, they can be static, local variables, created with new, and
destroyed with delete. Everything else works as before.
There is less documentation and less education for users, and the inter-
face is simpler, because you don't need to distinguish Fl_Shared_Image
objects from other Fl_*_Image objects when deleting them (delete vs.
release()).
(7) Disadvantages:
There will be more memory consumption for the Fl_Shared_Image objects.
The internal Fl_Shared_Image_intern object may be slightly smaller than
before, but there will be a real Fl_Shared_Image object (smaller than
today, but at least as big as an Fl_Image + one pointer), where we only
have a pointer today. But there will still be only one array(), and this
is the biggest part of the image.
Current sizes:
sizeof(Fl_Image)=28, sizeof(Fl_Shared_Image)=48
That's it for now. I'd like to hear your opinions.
If there is interest, I'd be willing to start working in a branch and
try to implement it.
Thanks for reading so far, I'm open for questions and discussions.
And please be kind and don't kill me for small errors or something
that might look wrong...
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
