On Fri, 23 Jul 2010 16:46:51 -0500 Denis Kenzior <[email protected]> wrote:
> Hi Kristen, > > On 07/23/2010 04:39 PM, Kristen Carlson Accardi wrote: > > On Fri, 23 Jul 2010 16:03:16 -0500 > > Denis Kenzior <[email protected]> wrote: > > > >> Hi Kristen, > >> > >> On 07/23/2010 03:52 PM, Kristen Carlson Accardi wrote: > >>> On Fri, 23 Jul 2010 15:03:59 -0500 > >>> Denis Kenzior <[email protected]> wrote: > >>>> > >>>> This also brings up another point. You're assuming that the caller is > >>>> appending the CLUT right after the image data and massaging the clut > >>>> offset appropriately. This is a really bad idea since the caller will > >>>> have to do some significant pre-processing. > >>>> > >>>> You can handle this in one of two ways: > >>>> > >>>> 1. Assume the calling logic will read the entire image file before > >>>> calling this function. In this case, modifying the signature as follows > >>>> might be a good idea: > >>>> > >>>> char *stk_image_to_xpm(const unsigned char *file, > >>>> unsigned short file_len, > >>>> enum stk_img_scheme scheme, > >>>> unsigned short img_offset, > >>>> unsigned short img_len); > >>>> > >>>> 2. Assume the calling logic is clever and will optimize reading of the > >>>> file, including peeking into the image header to determine the where the > >>>> CLUT is located and reading it. In this case you can either reuse the > >>>> signature from 1 above, or come up with something else. > >>>> > >>>> Remember, reading from the SIM is extremely slow, so any and all clever > >>>> optimization tricks are definitely wanted. > >>> > >>> So, is it likely given normal usage that we'll access an image a single > >>> image at a time, or is it more likely that we'll access a bunch of images > >>> all at once? It may be better to read an entire image data file (with > >>> multiple images) and keep it cached if we are likely to immediately > >>> need the other images. In which case I'd be inclined to just pass > >>> in the entire data image file and the offset like you have above. If > >>> we are only likely to use a single image for any given length of time, > >>> then it seems better to have the caller be smart and pass us the clut. > >> > >> The problem is we just don't know, so we have to assume the worst case. > >> Anything that minimizes the number of reads is a good thing (TM). > >> > >> For instance, you might have couple of dozen images from EFimg dispersed > >> among multiple EFiidf files. Each EFiidf file might be 65K in length, > >> but EFimg files might only refer to about 10k from all of them. > >> > >> It is perfectly OK for EFiidf to contain mostly garbage (e.g. for future > >> updates, installation of new SIM Toolkit applications on the SIM + > >> associated image data, etc) So you simply can't assume any sort of > >> packing or efficient storage use. > >> > >> In this case, a clever algorithm that minimizes the number of SIM > >> fetches is needed. > >> > >> Regards, > >> -Denis > > > > If that is the case then I propose we assume a smart algorithm fetched > > our data for us and change the signature to something like this: > > > > unsigned char *stk_image_to_xpm(const unsigned char *image_body, > > enum stk_image_scheme scheme, > > unsigned int height, > > unsigned int width, unsigned int ncolors, > > const unsigned char *clut); > > > > We would assume that the caller has done all the sanity checking on > > the file and handed us a clut of appropriate size as well. > > You sure you want unsigned char * as the return and not char *? Oops - no, I typed that wrong. > > Also, you might want to change unsigned ints to unsigned chars. The > image size and CLUT size can never be more than 256. > The image size can be greater than 256, but I think you mean the value of height, width, and ncolors can never be greater than 256, which is true. _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
