what patches are you interested in?

Bob -

I sent you a SampleImage() optimization patch a few days ago, but haven't 
heard back yet. I guess you are away right now.
Meanwhile, I would like to understand what types of patches you are interested 
in. I have several of them, but some have downsides. Here is an (uncomplete) 
list:

---1
Use the preprocessor (#define) or compiler (typedef) to make it possible to 
switch the C type used for floating point variables. I'm thinking about a 
patch that would allow either double or float.

---2
Add Drawxx() functions that render immediately without going thru the mvg 
string. I suggest to leave the current draw functions like they are (i.e. 
render delayed in DrawRender()), and add DrawLineNow() or similar (because 
some pattern operations relay on the ability to cache operations in some 
format, and the current string cache works nicely).
The reason to add DrawxxxNow() functions at all comes from waste of memory and 
CPU if you have large polygons (quite common in WMF, for example).

---3
cache cleanup. This is drastic, but I don't think competing and overlapping 
functions are of any value. Given your last answer to this topic, I would 
suggest to remove all cache functions except for the 'nexus' family.

---4
preprocessor defines to turn off certain features, e.g. the resource.h 
function family (e.g. #define GM_NO_RESOURCE_MGMT), the semaphores 
(GM_NO_SEMAPHORES), PseudoClass support (GM_NO_PSEUDO_CLASS)

---5
support for FILE* fopen() instead of int open() in cache.c

---6
magick/render.c:DrawImage() has unnecessary (?) allocation codes where it says 
'if (i >= (long) (number_points-length))'.

---7
magick/utility.c:AllocateString() should return 0 if source == 0, and should 
otherwise only allocate strlen(source)+1 bytes.

There will be more, but you get the idea.
My question is: How interested are you in such patches? Some of them have 
downsides (ABI incompatility, etc.), and I'm not sure whether you have a 
stable tree and a devel tree, or what policies you generally have for patches 
like the above ones.
My proposed cache cleanup would remove functions that others may be using, or 
even like, or whatever.
---
On our end, we would like to keep the link between our tree and the official 
gm tree as close as possible. Therefore, I will look into switching from CVS 
to the arch revision control system on our side hoping that arch will allow 
us to make all the changes outlined above even if you don't like them for the 
official gm tree (some we did already), and at the same time make it easy for 
us to propagate changes in both directions.

Regards,
Wolfgang



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn