texmacs-dev
[Top][All Lists]
Advanced

[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


Attachment: 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]