Crazy memory usage

That’s very similar to the ‘get_xml()’ method I referred to. It cached XML files on the web server and when the file wasn’t found, it performed a SLOW database fetch from a remote server. But hey, I’m not telling you anything you don’t already know.

public function get_xml($cid, $edit_mode=true) {
	$this->list_contents[] = $cid;
	$default_name = dirname(__FILE__).'/../content/'.$cid.'.xml';
	if (file_exists($default_name)) {
		$cid_xml = simplexml_load_file($default_name);
		$this->cid_labels[$cid] = $cid_xml->contents->content->attributes()->label;
	}
	else {
		global $xml_server_url;
		$cid_xml = simplexml_load_file( $xml_server_url."fsb_get_content.cgi?name=".$cid.xmlSuffix() );
		if (isset($cid_xml->contents) && isset($cid_xml->contents->content) ) {
			file_put_contents($default_name, $cid_xml->asXML() );
			$this->cid_labels[$cid] = $cid_xml->contents->content->attributes()->label;
		}
	}
	return $cid_xml;
}

Very interesting.
What is the difference to vector graphics?

Vectors aren’t smart. When an icon is a class that takes care of its own drawing it can respond to changes in background colour. It can decide to not draw certain details in certain zoom levels. It can decide to not show certain parts of the icon at all under certain conditions, which is handy if you have a bunch of icons that are all similar, or at least share certain aspects, you can design them as a single class which you can access from the outside so that it appears different. You can have icons that respond specifically to program state (time, date, system sound, or more specific things such as local colour palettes or validity states). It’s easier to have icons show different states and animate between them (well, some animations are easier in code anyway). It’s easier to share certain drawing routines between different icons.

Of course 99% of icons will be designed as a collection of vector shapes or as varying resolution bitmap images, but I’ve already created subclasses that can handle those. The basic design so far looks like (there’s more to it of course, but this is the important bit):

public interface IIcon
{
  void Draw(IconContext context);
}

public sealed class ImageIcon : IIcon
{
  public ImageIcon(IEnumerable<Bitmap> images) { }
}

public sealed class VectorIcon : IIcon
{
  public VectorIcon(IEnumerable<VectorShapes> shapes) { }
}

Where the vector shapes already support lots of functionality with respect to animation and states and category-hiding.

And if you want to create a custom icon that cannot be done using vectors or bitmaps, you create your own class:

public sealed MyIcon : IIcon
{
  public MyIcon(Arg1 first, Arg2 second, Arg3 third) { }
  public Draw(IconContext context)
  { 
    Color background = context.BackgroundEstimate;
    RectangleF frame = context.IconFrame;
    float zoom = context.UiZoomLevel;
    ...
    context.Graphics.DrawSomethingComplicated(data1, data2);
  }
}

If you can assume that an icon isn’t going to look different at different times of the day then you can render it into a bitmap and draw the bitmap instead. Then you do not have to load the code for the icon. It may also be a good way to short-circuit certain icons that were badly designed and take a long time to draw. You just know that some jerk somewhere is going to put a web-request inside the drawing routine and make every screen redraw last 4 seconds.

And, also a reasonably big benefit, you do not need graphics software to make decent looking icons. I’m actually working on a way to generate icon code straight from Rhino geometry, in case you still want to draw something by hand but don’t have InkScape or Illustrator or Xara handy, and I think we can all assume that people who make Grasshopper plugins have access to (A) Rhino and (B) a C# IDE.

That is a smart approach, very interesting!
And many thanks for the detailed explanation.

(BTW, I use Xara for icons.
And guess what, if it comes to complex shapes and trimming, I draw in Rhino and transport the center lines via AI.)

That was my m.o. as well for nearly a decade (and before that I made my icons using !ArtWorks on RiscOS). It’s a perfectly reasonable approach given the current ways in which we can provide icons, but I’m unhappy with the limitations. It would still be nice though to be able to convert *.ai files directly into GH Icon classes (and *.svg as well). Not sure whether/when I’ll get around to that.

As far as the memory usage issue goes; it would be best for us to get a better understanding of what is really causing the large uptick in usage before devising any solution. Rhino does a lot of this caching for plug-in data that grasshopper doesn’t have to do because it loads all components at start. Caching the information so you don’t have to load a component is very hard to get right (I’ve been fixing little caching bugs in plug-in management for years.)

I remember me programming my Commodore 64 (64kb ram) and later with C128 making cubes, rendering reflections with a software using Geos as OS.