long message - double support, notifications, user feedback

[John Biddiscombe]

My apologies for this lengthy message, please inform me if it should be
directed to the 

Part 1 double support
----------------------
As Bill (L) - (and maybe some others) have noticed, I started adding some
VTK_DOUBLE support.
vtkAppendPolyData highlighted exactly the sort of problem I expected.
Sending N inputs to vtkAppendPolyData didn't work if they contained points
arrays which were VTK_DOUBLE, because it created an output vtkPoints object
which was VTK_FLOAT by default, copies from inPts to outPts failed after
that.

Correcting the problem involved modifying a number of classes (thanks Bill)
and I expect that if I change any other filters a similar thing may happen.

My main concern is that many many filters create an output points array
which is VTK_FLOAT and so any data I send in gets irretrievably munged.
Really all filters which generate PointSet or derived classes should use the
same resolution for their outputs as for their inputs - unless there's a
good reason!. (ignoring multiple input filters for now!).

I'd like to add a function along the lines of
CreatePointsArray()
in vtkPolyDataSource (pointSetSource?)
which will examine the inputs and create a points array with the correct
type ready for the output.

However....this only half addresses the problem. All the filters have
float *myPtsData...etc etc etc
and use float all the time.

It's true that for visualization purposes float resolution is fine, but the
pipeline architecture is just too good to waste on visualization only.
Interfacing the visualization pipeline onto the "data pipeline" or the
"computation pipeline" is what most of us are doing (I expect), and there
are lots of useful filters which can be used for many applications.

I'm going to (slowly) start experimenting with a few filters and hopefully
find some elegant means of adding automatic preservation of datatype, If
anyone has suggestions or views, then I'll be glad to hear them.

Part 2 Notifications
---------------------
In the past, I've wanted to add an event callback to the ReleaseData /
SetNthOutput mechanism to enable a GUI to catch changes in data type.

Since there's only myself wanting this, it doesn't seem fair to add it in.

The main objection to a callback of the type above is that it could lead to
a proliferation of
SetThisEventCallbackFn(
SetThisEventCallbackArg(
SetThisEventCallbackArgDelete(

But...While pondering ways around this, I was thinking about the windows
message
WM_PARENTNOTIFY
which windows sends out to a parent, when child windows do things.

and on and on. But a possible way around this would be to have a single

SetEventHandlerFn(...
SetEventHandlerFnArg(...
SetEventHandlerFnArgDelete(...

and define messages along the lines of
VTK_SOUCE_OUTPUTDELETE
VTK_SOUCE_OUTPUTASSIGN
VTK_PROCESS_BEGINUPDATE
VTK_PROCESS_ENDUPDATE

etc etc (they're just made up examples). And provide a small buffer (void
pointer) for args/data etc etc (like wParam, lParam).

Each vtkObject would have a single event handler and it could be reused by
any process/filter to supply callback messages to the parent program.

A single vtkMessageDefinitions.h would contain valid IDs and optionally a
macro like VTK_USENOTIFICATIONS_ON/OFF (c.f. VTK_LEAN_AND_MEAN) could be
used to enable/disable them via
vtkSendNotification(VTK_SOUCE_OUTPUTDELETE,argpointer...)
similar to debug messages being turned on and off.

good idea?

no?

Part 3 user feedback
--------------------
When writing embedded filters. by which I mean, filters whgich contain more
filters, I'm frustrated by the fact that I can't put additional information
inside the UpdateProgress(...) handlers to give
a) more detailed info, such as "starting BSP tree build", "Raytracing",
"Collecting results"
b) the ability to pass updates down or up the filter heirarchy so that
embedded filters can be "visible" inside their owners

I'd like to add functionality to ProcessObject to support this. If anyone
has comments....



John B