Claudio Saavedra

claudio@codemonkey.cl

Go forward in time to March 2008.

Mon 2008/Feb/25
  • I got a nice suprise today in the mail: Lucas sent me a lovely Eye of GNOME T-Shirt!

    EOG hacker and his EOG
		T-Shirt

    This is one of those small acts of kindness that make me love the free software community. Thank you a lot, dude!

Fri 2008/Feb/22
Thu 2008/Feb/21
Sat 2008/Feb/16
Fri 2008/Feb/15
  • Last month, I went to Valparaíso. I stayed for a few days, and took the chance to visit a bit more of the lovely puerto. This time, I took walks on the Cerro Alegre, Cerro Concepción, Cerro Bellavista, Plaza Sotomayor, and other interesting places.

    I almost visited La Sebastiana, one of Pablo Neruda's houses. I declined visiting it, for the same reasons I got really upset when I visited Isla Negra while I was still in high school. Prices for students are reasonable, but only valid during weekdays. So, if you are a student from a different city who can only travel to Valparaíso during the weekend, you have to pay a normal fare, which is pretty unfair. I had forgotten about that (high school was like 7 years ago), but had the same feeling this time. So I rather not visit it.

    Valparaíso is really colorful. With a sucky camera like mine it's hard to depict the beauty, but either way, I made a few pictures.

    Cuatro botes

    Ascensor Espíritu Santo

    I love the colors but I hate the pole

    With Betti and Marie we went to Viña for the day. That city was really crowded and there was way too many people around. I wonder why people is so obsessed with making vacations in Viña, when it clearly sucks to share every m2 with three or four people. I'm glad the girls lived in Valparaíso, and not there.

    summer?

    Bettina already flew back to Dresden. Marie will leave next Tuesday. I'm thrilled to think that it's unlikely that we will meet again, once she's gone.

Fri 2008/Feb/08
  • I couldn't help it. I had to hack a bit today.

    A report coming from Launchpad showed that EOG needs a lot of memory to load big bitonic TIFF images. These images shouldn't really use so much memory, as, in the best case, only 1 bit is needed to store each pixel. An image of 15000x5000 pixels then would only need about 9 MB in memory, but due to some limitations in libtiff and GdkPixbuf, we require 4 bytes per pixel, meaning that instead we need about 286 MB. Certainly a waste, but not much that we can do at the application level.

    Something surprised me, though. Loading a 5 MB TIFF image in EOG for the first time almost killed my poor laptop. But, loading it a second time, showed that even when ridiculous amounts of memory were required, the responsiveness was better and load time was much less. So, I decided to investigate what was going on there.

    I used valgrind's massif to check what was going on. Opening the evil TIFF image from a newly created directory, produced this output:

        MB
    552.7^                             ,.. .. .., . .. .. .,.#...                 
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                          @  @:: :: ::@ : :: :: :@:#:::             :   
         |                ,    @....@  @:: :: ::@ : :: :: :@:#:::             .   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |                @    @::::@  @:: :: ::@ : :: :: :@:#:::             :   
         |            .. ,@    @::::@  @:: :: ::@ : :: :: :@:#:::             : ..
       0 +----------------------------------------------------------------------->Gi
         0                                                                   12.07

    The first band, at around 280 MB, represents the memory used when the image is first loaded. The second one appears when EOG loads the thumbnail for the image. As you can see, it's the double than the first one!

    Problem here is that the thumbnailing code in eog-thumbnail.c comes from eel. The API for this is something like

    GdkPixbuf *eog_thumbnail_load (GnomeVFSURI *uri, GError *error);

    which means, that EOG passes a URI to the loader, which, in case the thumbnail doesn't exist under ~/.thumbnails, needs to load the image from the given URI and create the thumbnail. Something here is wrong, isn't it?

    Well, that API makes sense in nautilus (I suppose that this eel code is from nautilus, not sure, though), because nautilus never has an instance of the image already loaded in memory. EOG, on the other hand, sometimes may have the image already in memory, so in these cases, it's not necessary for GnomeThumbnail to load the image again in order to thumbnail it.

    So, I decided to change the API a bit, and instead have a

    GdkPixbuf *eog_thumbnail_load (EogImage *image, GError *error);

    that will work as follow: first, try to load the thumbnail from ~/.thumbnail. If it doesn't exist or it isn't valid, check if the EogImage instance has already the pixbuf loaded. If it does, scale it, tell GnomeThumbnail to save the scaled version as the thumbnail, and use it as such in the application. If it doesn't, tell GnomeThumbnail to create the thumbnail from the URI, the usual way.

    The same test case after this patch reduces the memory usage to the half during thumbnailing. Massif's output:

        MB
    286.8^            #                                                           
         |           @# : ...   ....... .,.. .  .@  :....,.. ..,.., .,....,.....  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         |           @# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::  
         | ,. . ., .,@# : :::   ::::::: :@:: :  :@  :::::@:: ::@::@ :@::::@:::::.:
       0 +----------------------------------------------------------------------->Gi
         0                                                                   16.63

    I know what you are thinking. Using 280 MB for a bitonic image still sucks, but I don't think we can do much more at the application level. The good thing is that this beast gave me some hints on what to do to make EOG a bit faster.

    Still a lot of other places in EOG where to look for improvements and optimizations, but I should go back to finishing my dissertation before February ends first.

    (yes, I wrote all this here only as a way to procrastinate even more)

Thu 2008/Feb/07

Go backwards in time to January 2008.

Thu 2008/Feb/07 12:18:04 -0300