texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] eps image is pixelated


From: Miguel de Benito Delgado
Subject: Re: [Texmacs-dev] eps image is pixelated
Date: Mon, 19 Aug 2013 11:00:53 +0200


On Fri, Aug 16, 2013 at 4:11 PM, Michael Lachmann <address@hidden> wrote:

On 16 August 2013 14:58, Miguel de Benito Delgado <address@hidden> wrote: 
In my machine the file loads fast (<1sec) and I notice no difference between first load and subsequent loads after closing the buffer. But scrolling sucks because each time the canvas is shifted, Ghostscript is called. Activating the in-memory caching system results in perfectly smooth scrolling as if no images were there.

Sorry, when I said above "load", I meant scrolling time. So, start TeXmacs, load the file, scroll to the bottom, you'll see significant delays. Scroll again, there are no delays. Close the file (but not TeXmacs), load it again, again scroll with no delays. Close TeXmacs, open it again, load the file, again scroll with delays. 

That's weird, the bumpy scrolling happens to me no matter how often I scroll up and down. I even set a breakpoint at the point where gs is called, and the hit count goes up by several dozens with each pass over the images.
 
Maybe we could simply activate the cache already implemented in src/Graphics/Picture/picture.cpp for all images as I suggested, then persistently store it?  Note that there already is some infrastructure to this end, in src/System/Misc/persistent.cpp.
For images embedded into files we could do the following: upon load they are currently assigned some unique name like ~/.TeXmacs/system/tmp/tmp_1234567890.eps, then converted using gs. Persistently storing the cache would achieve nothing in this situation because it is indexed by URL, it'd just fill up the drive. CRC seems the way to go here yes, but then the relevant parts of the code relying on these tmp_stuff.bla names could be changed to use the CRC as filename, and we may use the current cache and persistently store it.

So: persistent storage of the cache in src/Graphics/Picture/picture.cpp and by-CRC naming of the temporary files related to embedded images.

Thoughts?

I think that is the correct approach in terms of where to put it in TeXmacs. I have a bit of a hard time understanding how persistent_write() works. If I understand correctly, it isn't currently used, so we can't do much damage.

I've used it to store results of documentation parsing, for inline docs of scheme functions. If you alt+click on some scheme function in a session or scheme file (with developer tools on) it should trigger the scanning of the docs. Sadly it isn't (yet) very useful due to bugs and most of all lack of documentation, which is the reason I don't devote much time to it any more. You can see the scheme code in progs/doc/apidoc-collect.scm. The C++ usage is pretty much the same.
 
(I'm also not totally sure how safe that part is with respect to multiple instances of TeXmacs running).

Pretty unsafe.
 
Do you really have to change the tmp_stuff part? That seems like a big change. Couldn't you
just add caching by CRC (and requested width/height) instead of by filename?

My guess was this: changing the file name would require a couple modifications, since it is most likely done via some "create_temporary_file_name" function or something like that, that will also be used at some particular point in the execution of the document tree when an inline image tag is found. One just implements the new naming scheme, then adds persistent storage to the current in-memory cache.

On the other hand, adding a whole new caching system seems pretty much more complicated, but maybe you have some simple solution in mind.

The first solution also has the boon to other users of the image caching system that they get automagic persistent storage (if they want to). However I'm not sure there are any more places where it is used, I haven't checked.

Best,
--
Miguel de  Benito.
 

reply via email to

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