I think... great! But I'd change some things first:
On Tue, Aug 2, 2011 at 16:59, Michael Lachmann
<address@hidden> wrote:
I think that everybody will agree that image rendering in TeXmacs is currently quite broken.
I think that's a polite understatement
If I understand correctly, an imported image is first converted to eps. (I think using the scheme conversion methods). Then, when the image is displayed,
src/Plugins/Ghostscript/gs_utilities.cpp
Is called, which is hard coded to use gs with certain parameters. Then, when the file is exported, the image is again converted, if necessary. I think TeXmacs should keep the image in the original format, and render it from there. On printing it might be converted, or not. And, I think that image rendering should be done in the background so that TeXmacs does not get stuck every time an image is displayed....
I have no idea if what you said is correct or not, so I cannot help. But I couldn't agree more with the background rendering. Some threads would come in really handy here.
As a temporary remedy, I added a hack...
First of all, calling gs is not hard coded in TeXmacs. Instead an external script is called. (hard coded in my version ;)
Since we use an external script, we can try different things... maybe use gs correctly, or some such.
The script I ended up using simply calls gs exactly like TeXmacs originally did, except that it caches images. So if an image is rendered once in a certain resolution, the cached version is used, instead. The cache uses
~/.imagecache/[CRC32 of image]/img_404x449_90x90.png
Where 404x449_90x90 are the requested resolutions of the image.
First, I would change the default location for the cache to something inside .TeXmacs. I would also suggest we/you think of another naming scheme which avoided creating thousands of entries in the same directory, since many filesystems (all?) suck at managing this. Yet another suggestion, more in the realm of wouldn't-it-be-great's: why not ditch the one-file-per-resolution idea and use some format like JPEG2000 which allowed for multiple resolutions in one file (or so I gather it does from the fact that it's wavelet based, please correct me if I'm wrong).
For now, it works nicely for me. Sadly, there isn't really a facility to redraw an image when something goes wrong, so you might have to erase ~/.imagecache
I do not understand what you mean by "a facility to redraw ... wrong". And actually, a management interface for the cache system would have to be implemented in order for this solution to be used.
This whole thing is a horrible hack. But since I work with images that take 20 seconds or more to render (just a simple 50x100 density plot from R, nothing fancy), and a document will have many of those, scrolling through the document was really maddening.
So it's already way better than the original situation, which makes the horrible hack a lovely horrible hack. If you have some time to spend in it and can make it less horrible and more lovely, that would be just great.
By the way, one could also consider embedding the data into the .tm file (using \raw-data?), if it's not too much weight. This would mean duplicate thumbnails for different .tm files which used the same image, though, so it might not be such a good idea, but would also discard cached thumbnails of images which changed often (meaning: changing the image file would result in a cache update which would replace the old data directly in the .tm file).
Another possibility could be creating cache directories for each .tm file or, better, project: one item which has been in my personal to-do list for ages is (better) project management (with configurable image/style/script/aux folders and any other niceties), and this would fit well into that.
The rationale against the global cache is that it could get huge, but then, it would just be a matter of automatically checking and cleaning upon startup, so it might just be best. Hmm... yes, I think your idea is better.
Regards,
________________
Miguel de Benito.