[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] slow images..... and slight improvement hack
From: |
Michael Lachmann |
Subject: |
Re: [Texmacs-dev] slow images..... and slight improvement hack |
Date: |
Wed, 14 Sep 2011 16:10:24 +0200 |
Hi Joris,
I'm not sure if you already went through the whole pile of texmacs-dev mails...
I just wanted to see what you think about the hack I posted below. I have been
using this for around 1.5 months, and it seems to work quite well. Images load
MUCH faster than before. I think that the cache handling is probably better
handled from inside TeXmacs instead of by an external script as I do. In any
case I think it is a good idea not to have the image conversion ps-to-png
hard-coded into TeXmacs.
(Instead of what is written below, because of feedback from the mailing list, I
put the image cache in .TeXmacs/system/cache/images, and the CRC is separated
into letters with a directory for each letter. Its current size for me, after
1.5 months of use is 13M. )
Michael
ps_to_png
Description: Binary data
On 2 Aug 2011, at 4:59PM, Michael Lachmann wrote:
> Hi,
>
> I think that everybody will agree that image rendering in TeXmacs is
> currently quite broken.
>
> 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....
>
> 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.
>
> 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
>
> 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.
>
> Anyway, here is the script and the edits.
>
> The edit to src/Plugins/Ghostscript/gs_utilities.cpp is to replace gs_to_png
> with:
> ----
> void
> gs_to_png (url image, url png, int w, int h) {
> #if defined (__MINGW__) || defined (__MINGW32__)
> string cmd= "\"";
> cmd << get_env ("TEXMACS_PATH") << string ("\\bin\\gswin32c\" ");
> #else
> string cmd= "/usr/local/bin/ps_to_png ";
> #endif
> cmd << " " << as_string (w) << " " << as_string (h) << " ";
> int bbw, bbh;
> int rw, rh;
> gs_image_size (image, bbw, bbh);
> rw= (w*72-1)/bbw+1;
> rh= (h*72-1)/bbh+1;
> cmd << " " << as_string (rw) << " " << as_string (rh) << " ";
> cmd << " " << sys_concretize (png) << " ";
> cmd << sys_concretize (image);
> system (cmd);
> }
> ----
>
> What do you think?
>
> Michael
>
> <ps_to_png>_______________________________________________
> Texmacs-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/texmacs-dev
- Re: [Texmacs-dev] slow images..... and slight improvement hack,
Michael Lachmann <=