| |
| |
On 4/30/21 10:52 PM Bill Spitzak wrote:
I would prefer if the call to get an image was in the same namespace as
calls to send an image, thus not methods of Fl_Window, unless all
drawing was made into methods of Fl_Window.
Bill, thanks for your comment. I understand the words, but I don't
understand what you exactly mean and particularly *why* you think that
would be better.
WRT drawing methods: as an example we have Fl_[derived_]Image::draw()
and we have fl_draw_image(), i.e. we have in this case two entirely
different draw() methods / functions. Both have their usages.
My proposal Fl_Window::capture() would have the additional advantage
that it could be virtual and be reimplemented differently in
Fl_Gl_Window w/o needing to query the window type in the function
fl_capture..(window, ...).
Looking forward to your reasoning...
It would make sense to update the api so that it can be implemented by
returning pointers to memory already allocated by the drawing library,
however.
That's another point I really don't understand. What "api" should be
updated, and what do you mean with "returning pointers to memory already
allocated by the drawing library"?
Hmm, do you mean the api of fl_read_image()? This allows already to use
NULL for the pixel buffer so FLTK allocates the data buffer internally.
Is this what you mean?
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/2d7c746d-1873-38c8-b370-6812e7df8c91%40online.de.
[ Direct Link to Message ] | |
|
| |
