Changes between Initial Version and Version 1 of Ticket #6964, comment 5


Ignore:
Timestamp:
2011-10-16T23:34:41+02:00 (13 years ago)
Author:
simon04

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #6964, comment 5

    initial v1  
     1Damn: trac encountered an error and my comment was lost …
     2
    13Replying to [comment:4 bastiK]:
    2 > Replying to [comment:3 simon04]:
    3 > > By (a) resizing the presets icons to 16x16 pixels, (b) putting all images from `images/` to a zip archive and (c) putting all images from that archive in a HashMap, I could gain another ≈0.7s for initializing `TaggingPresetPreference`.
    4 > >
    5 > > When deploying this, one would need to adapt the `build.xml` in order to perform the steps (a) and (b) automatically.
    6 > I don't understand (b) and (c). Isn't the jar file a zip file, so you'd have zip inside zip? There is a trick in web design, where you arrange a large number of icons in a grid on one single image file (in order to save network overhead for many small files). Not sure it is any good for normal desktop applications.
     4> I don't understand (b) and (c). Isn't the jar file a zip file, so you'd have zip inside zip?
    75>
    86> How is (c) different to what ImageProvider does at the moment?
    9 >
    10 > Regarding (a): When the images are never used beyond 16x16, it sounds reasonable to distribute the lower resolution. While you're at it, some icons could be shared between presets and default map style. E.g. there is no reason, to have different bollard symbol for each.
     7
     8I'm not sure about this: Could it be that Java gets resources one by one, i.e., reads the jar for every image requested?
     9
     10I'll attach my changes. The archive `images.zip` contains `images/` and all its content.