Difference between revisions of "Performance/Meetings/2009 01"

Latest revision as of 23:12, 17 March 2010

Performance/Meetings/2009/01/16

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2009/01/16
Time: 15:42– 16:49
Meeting No.:

Agenda:

(4:27:35 PM) liheng: Malte:Hi!
(4:28:13 PM) odf-mib: Hello everyone
(4:28:18 PM) yugq: Hi all:-D
(4:29:36 PM) FrankL: Hi, all
(4:29:41 PM) liheng: Hello, everyone
(4:29:59 PM) sb: hi
(4:30:24 PM) Dieter__: Hi all :-)
(4:31:36 PM) Matthias: Hi all
(4:31:42 PM) xiuzhi: hi all
(4:31:54 PM) Matthias: xiuzhi: moin
(4:32:16 PM) Matthias: liheng: hi
(4:32:19 PM) xiuzhi: mhu:moin & goten tag
(4:32:30 PM) Matthias: :-)
(4:32:52 PM) liheng: Matthias: Hi :)
(4:33:08 PM) Dieter__: liheng + xiuzhi: hi!
(4:33:30 PM) liangjun: hello :)
(4:33:31 PM) xiuzhi: Dieter__:Hi moin
(4:33:53 PM) liheng: This is agenda
(4:33:54 PM) liheng: Topics: 1.To discuss weighting and testing-cases of User Experience Index 2.To continue discuss improving loading/saving with asynchronous processing media files
(4:34:26 PM) liheng: I had to attend a meeting so YuGuoqiang sent it to you all:)
(4:35:01 PM) Matthias: yes, we received the agenda
(4:35:56 PM) liheng: Dieter__:By the way, we can get some suggestions for Incubator Project from chinese forum :(
(4:36:31 PM) Dieter__: liheng: some negative feedback?
(4:37:20 PM) liheng: only 2 feedback, one is agree, other is from Peter
(4:37:43 PM) Matthias: liheng: can you explain in a few words, what "chinese forum" that is, please ?
(4:39:11 PM) Dieter__: liheng: the feedback on the dicsuss list at OOo is pretty good and I will ask Louis on Monday to accept and create the Performance project
(4:39:51 PM) liheng: Matthias:I choose two forum websites ,CSDN.net and BlUG(Beijing Linux User Group) to publish our proposal of Performance Project to get some suggestions:)
(4:40:08 PM) liheng: Dieter__:Thank you very much!:)
(4:40:33 PM) Dieter__: liheng: you're welcome!
(4:41:11 PM) liheng: We have published the UEI(User Experience Index) case description and weighting on wiki, http://wiki.services.openoffice.org/wiki/UEI
(4:41:40 PM) Malte: Thanks :)
(4:42:09 PM) Malte: For me, most of them look quite reasonable
(4:42:27 PM) Matthias: liheng: okay, thanks for the explanation
(4:42:43 PM) Malte: I have one suggestion to UEI:
(4:43:19 PM) liheng: Matthias:You are welcome!
(4:43:22 PM) Malte: We should completely seperate Startup Cold/warm, because it's relevant for the EI
(4:43:29 PM) Malte: UEI...
(4:43:50 PM) Malte: Slow warm start has a much higher UEI than cold start, IMHO
(4:44:05 PM) Malte: Cold start UEI should be smaller than load/save docs
(4:44:19 PM) Malte: Warm start ,ight be higher
(4:45:06 PM) liheng: Malte:Yes,so we rise proportion of warm start to 65%
(4:45:54 PM) Malte: I would suggest to leave warm start UEI on 80, but set cold start UEI to 50-60
(4:46:09 PM) Matthias: Malte: but you always start your day with a Cold Start of OOo ... and than have it open all day ... so I see it more important
(4:46:37 PM) liheng: Malte:
(4:46:52 PM) Malte: I don't think that the cold start UEI should be higher than load/save
(4:47:06 PM) Malte: load/save is done much more often
(4:47:17 PM) Malte: and also warm start is done much more often
(4:47:26 PM) Matthias: maybe not
(4:47:44 PM) FrankL: Has the index been tested with real users?
(4:48:42 PM) liheng: FrankL:We get some suggestions from end users by Product Dept CH2000
(4:49:44 PM) yugq: I think the Most Important aspect comes from the First Impression, so I think cold start is more important than warm start. From another point of view, the performance of warm start depends on cold start, so UEI of cold start should be higher :)
(4:49:47 PM) liheng: Malte:We make cold/start in a value because they do some things but system context is different
(4:51:01 PM) liheng: Malte: And startup is the highest weighting in all item
(4:51:25 PM) FrankL: But what happened more often. Cold or warm start?
(4:52:07 PM) FrankL: Also saving documents seems a major task for users and we have autosave that runs every 10 Minutes by default.
(4:52:40 PM) liheng: But we get situation from end-user maybe cold:warm is 35:65
(4:52:50 PM) Matthias: well, the distinction between "cold" and "warm" start is a complex function of the "system" and it's usage history.
(4:53:55 PM) Matthias: ...and "cold" and "warm" start situations may occur multiple times a day in succession
(4:54:23 PM) Matthias: ...in particular with portable (laptop) computers
(4:54:30 PM) liheng: FrankL:We effort to make saving to asynchronous and increasmental
(4:54:47 PM) FrankL: If quick starteris not installed.
(4:55:03 PM) yugq: FrankL: I agree save is more often happened. So UEI of it should be higher than others. But cold start and warm start have some relationship. If the cold start performance is good, then warm start also perform good.
(4:55:22 PM) FrankL: liheng:OK. That would be very good!
(4:55:39 PM) Matthias: not every operating system has a "quick starter" (or may not have the memory for it) (or may have a SSD where startup is faster) (...)
(4:56:34 PM) liheng: Matthias:I agree!
(4:56:46 PM) Matthias: liheng: :-)
(4:58:27 PM) FrankL: Bu the majority of users uses a system providing this technical helper ;-)
(4:58:37 PM) Matthias: how do you know ?

(4:59:11 PM) Matthias: maybe the majority will use Intel ClassMate PCs with Linux in the future
(4:59:18 PM) FrankL: By download numbers and hopefully by usage tracking which will start with OOo 3.1.
(4:59:21 PM) liheng: Malte:We already have risen the warm start to 65%,we think it's enough :)
(5:00:41 PM) Malte: Well, maybe I was not clear enough - I don't talk about the "proportion", but the "Weighting of Item".
(5:01:21 PM) Matthias: and the overall weighting is "start = 80", "save = 70" , "load = 60", so what would be missing here ?
(5:01:23 PM) FrankL: Each user has a different feeling of what is an acceptable performance. Furthermore it depends on the tasks the user iis doing and the situation the user is in.
(5:02:31 PM) Matthias: FrankL: sure, nobody questions that
(5:03:23 PM) Malte: mhu: I miss that I agree on start weighting > load/save for the warm start, but not for cold start.
(5:03:26 PM) Malte: My opinion.
(5:03:29 PM) liheng: FrankL+Matthias:These survey items is common, and we need only evaluating majority value
(5:03:51 PM) Matthias: Malte: but all others agree here
(5:04:06 PM) FrankL: mhu: OK. But if we agree to use an index to measure if the performance is OK, we should be sure that this index works for sure.
(5:04:15 PM) Malte: But I was asked for my opinion, so I state it...
(5:04:22 PM) Malte: I didn't say I want to discuss further
(5:04:22 PM) xiuzhi: Let's see one case. When you want to look through one webpage, if the open time is more than 3s ,Nomally one people will give up
(5:05:14 PM) Malte: Right, but the browser start-up is allowed to take 10s ;)
(5:06:02 PM) sb: I am not sure whether it is worth it to discuss the details of the index: Startup is considered slow, load is considered slow, save is considered slow. We need to work on all three. Working on them will reduce the index number. For now, that IMO is enough to guarantee that we are on track. Once things have settled, we can revisit the index calculation.
(5:06:33 PM) FrankL: I will prepare usage scenarios to get a common understanding when performance issues occur.
(5:06:33 PM) Matthias: right
(5:07:01 PM) Malte: Maybe I misinterpret the index.
(5:07:12 PM) Malte: For me the values don't change when we optimize OOo
(5:07:20 PM) Matthias: FrankL: please consider also hardware that maybe common in 1 or 2 years (nettops ...)
(5:07:40 PM) Malte: They are not "priorities" for working on items, but "state what is important for users
(5:08:09 PM) sb: Malte: I think the UEI is calculated as follows (correct me folks if I am wrong):
(5:08:13 PM) FrankL: mhu: OK
(5:08:28 PM) xiuzhi: Malte: normally it is right. so the weight between startup and load and save need to gather more end-users feeling. but now the startup is P1
(5:08:30 PM) liheng: I think we make first report with is table, and we discuss again with the result:)
(5:08:31 PM) Matthias: FrankL: thanks
(5:08:55 PM) Matthias: sb: yes?
(5:09:54 PM) sb: Take actual measurements (in seconds) of startup/cold, startup/warm, load/large, load/small, etc. Combine startup = startup/cold*.35 + startup/warm*.65, etc. Combine sum = 80*startup + 60*load + ...
(5:10:07 PM) sb: right?
(5:10:13 PM) Matthias: right
(5:10:30 PM) liheng: sb:Yes
(5:11:49 PM) Malte: Right - so the weight value means "What is important for the user", and not "what is good/bad now".
(5:12:08 PM) Matthias: right
(5:12:40 PM) Malte: So I don't understand the statement above: "Working on them will reduce the index number"
(5:12:57 PM) Malte: I will reduce the calculated value, but not the weight value
(5:13:12 PM) Matthias: yes, of course
(5:13:12 PM) Malte: And the weight number is the thing we discuss now
(5:13:32 PM) Matthias: no, all except you have agreed on the current weights
(5:14:16 PM) Malte: I "agreed but committed", as I said before
(5:14:26 PM) sb: Malte: I argue that the weight numbers are of little importance, and there probably will never be weights that satisfy all situations, anyway. Just using "random" values for now should work.
(5:14:51 PM) Matthias: thanks, Stephan
(5:15:26 PM) sb: Just one nit: you can reduce the weights by their common factor 10 ;)
(5:15:30 PM) liheng: Malte:I think we make first report with is table, and we discuss again with the result:)
(5:15:55 PM) Malte: Fine for me...
(5:16:58 PM) liheng: Ok,we have 15 minutes for 2nd topic,To continue discuss improving loading/saving with asynchronous processing media files
(5:17:46 PM) Matthias: yes, interesting results
(5:17:53 PM) xiuzhi: JackieSun: hello
(5:18:19 PM) JackieSun: xiuzhi: I am here
(5:18:33 PM) xiuzhi: JackeSun: :)
(5:18:54 PM) odf-mib: I agree. In particular for loading, I don't think that there must be a difference between the linked and the embedded case.
(5:19:20 PM) Matthias: yes, I would also not have expected that factor 2 diff
(5:19:51 PM) odf-mib: JackieSun: In the linked case, you load JPGs. Are using PNG or JPG in the embedded case?
(5:19:58 PM) Malte: factor 2 might be png/jpg issue
(5:20:26 PM) odf-mib: Malte: Yes, that was the background of my question.
(5:20:28 PM) Malte: test needs to be done with corrected documents
(5:20:53 PM) JackieSun: odf-mib: I am sorry for I am not sure
(5:21:24 PM) Malte: yugq: Would you please do the test again and post results?
(5:21:40 PM) yugq: Malte, sure.
(5:21:58 PM) Malte: Thanks :)
(5:22:17 PM) JackieSun: in the maillist, somebody think that downscaling the image is not agreeable
(5:23:11 PM) JackieSun: in some special field, like magzine, printing, they must need the high-res image
(5:23:33 PM) yugq: Malte, I think I didn't describe the problem clearly in the first mail. So I'll verify the test and report it again. But it will be next week:)
(5:23:37 PM) odf-mib: JackieSun: I think we should revisit this when we know that we are talking about the same data for linked an embedded cases
(5:24:56 PM) liheng: JackieSun:I can't agreed, the original image must pack into file, if we do downscaling, we lost data without asking user
(5:25:32 PM) lihen1: JackieSun:I can't agreed, the original image must pack into file, if we do downscaling, we lost data without asking user
(5:25:41 PM) yugq: odf-mib: It really happened not the same in the two case.
(5:26:02 PM) JackieSun: lihen: yes. I has changed my option
(5:26:11 PM) odf-mib: If we have solved that issue (or do know that we can't solve this), we should check if downscaling is an option.
(5:26:13 PM) Malte: I would add a option to OOo (Impress):" Optimize new images for screen display"
(5:26:28 PM) Malte: Then all newly inserted images can be optimized
(5:26:45 PM) Malte: Doesn't affect old documents
(5:27:08 PM) odf-mib: Malte: I'm still not convinced that we need this option.
(5:27:22 PM) Malte: UX might have an opinion.
(5:27:26 PM) JackieSun: in the maillist, the result is two ways: one is keeping the downscaled image to display in screen and ori-image to print etc.
(5:27:46 PM) Malte: IMHO people want small files, w/o using an extra step like the presentation minimizer
(5:27:54 PM) Malte: And of course w/o thinking about it ;)
(5:28:22 PM) FrankL: Malte: Then the image will be reduzed when saving. I user decides to enlarge the image again, then the data she need is gone.
(5:28:25 PM) odf-mib: I'm fine with it it turns out we need it. But first, I would like to understand why the embedded case is so much slower, and I would like to learn from UX whether the times for the linked case are acceptable.
(5:28:29 PM) Malte: Problem might be resizing the image after insertion
(5:28:35 PM) JackieSun: another is give an option to let user decide whether save the ori-image
(5:28:42 PM) xiuzhi: odf-mib: I prefer option for that,
(5:28:49 PM) Malte: Sure, this is not a workaround for performance
(5:30:03 PM) odf-mib: If we want to have this optioin for other reasons or anyway, then this is fine for me.
(5:30:22 PM) lihen1: Malte:We can create thumbnail for screen displaying
(5:30:50 PM) FrankL: and interlaced loading of images...
(5:30:54 PM) JackieSun: yes, only the downscaled image for screen displaying
(5:31:13 PM) Malte: If the original (big) image is in the file, then I would prefer loading to be fast, instead of caching reduced images :)
(5:31:32 PM) odf-mib: Before we discuss the options we have: Wouldn't it be better to get new numbers for the linked/embedded comparison first, and to understand them?
(5:31:35 PM) Malte: And I don't think that interlaced loading makes much sense in ODF
(5:31:54 PM) Matthias: the data loss argument is also relative, I think, as usually inserting an image means to insert a copy (by value) from a picture gallery (not the original file reference). So, I can reinsert it a dozen times if I so like.
(5:31:55 PM) Malte: The file is already local, interlaces loading is for slow connections
(5:32:48 PM) FrankL: Malte: I can give you a demo with a larger document in Writer. Or think about Impress.
(5:33:17 PM) Malte: The demo will show me that it's slow, but I doubt it will convince me the interlaces loading would help
(5:33:21 PM) lihen1: FrankL:Please send me a copy:)
(5:33:39 PM) lihen1: FrankL: Please send me a copy:)
(5:33:49 PM) Malte: I guess you want delay load, not interlaces load
(5:33:54 PM) FrankL: I will create a demo document that we can share.
(5:34:43 PM) lihen1: Malte:Yes, I really want to do lazy process for all media objects
(5:34:43 PM) FrankL: Malte: My intention is to be able to scroll through the document while images are loading.
(5:34:50 PM) odf-mib: yugg,JackieSun: Could you repeat your linked/embedded test with a downscaled version of the image. If we compare this with the test results for the original image, we should get some better understanding how much time we can save.
(5:35:09 PM) JackieSun: ok
(5:35:52 PM) lihen1: odf-mib:OK, we will do a group of test for this, and send the result and documents to you all
(5:36:24 PM) Malte: Thanks! :)
(5:36:27 PM) odf-mib: liheng: Thanks.
(5:37:07 PM) lihen1: It's my pleasure :)
(5:37:45 PM) JackieSun: let's go home?
(5:38:08 PM) lihen1: JackieSun:That all for me:)
(5:38:16 PM) Matthias: yes, have a nice weekend
(5:38:20 PM) JackieSun: i will late for the bus.......
(5:38:37 PM) JackieSun: ok, see you next time
(5:38:38 PM) lihen1: Matthias: Same to you
(5:38:43 PM) xiuzhi: JackieSun: see you
(5:38:48 PM) Matthias: thanks, bye all
(5:38:53 PM) odf-mib: Have a nice weekend. Bye
(5:38:58 PM) Malte: Thanks, bye :)
(5:39:03 PM) lihen1: Bye!
(5:39:14 PM) FrankL: bye!

Performance/Meetings/2009/01/09

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2009/01/09
Time: 16:29– 15:29
Meeting No.:

Agenda:

(4:29:59 PM) Matthias: Hi, all; good morning / afternoon; happy new year
(4:30:01 PM) yugq: Happy new year to all!
(4:30:01 PM) xiuzhi: hi all
(4:30:16 PM) xiuzhi: JackieSun: Are you Sui yinan?
(4:30:25 PM) JackieSun: xiuzhi ,yes
(4:30:25 PM) yugq: JackieSun, hi!
(4:30:31 PM) liheng: Hi,all!
(4:30:35 PM) odf-mib: Hi all!
(4:30:36 PM) JackieSun: I am Sun Yinan
(4:30:39 PM) liheng: Happy new year!
(4:31:16 PM) Dieter_: Hi all :-)
(4:31:18 PM) xiuzhi: Hi all
(4:31:50 PM) Matthias: Hi liheng, xiuzhi, all
(4:31:54 PM) FrankL: Hi, all
(4:31:56 PM) JackieSun: Let's begin?
(4:32:14 PM) Dieter_: Yes, let's start. Malte is on vacation.
(4:32:15 PM) xiuzhi: JackieSun: Please follow the agenda
(4:32:24 PM) JackieSun: ok
(4:33:27 PM) liheng: 1. Plan to work out first User Experience Index for OOo
(4:33:27 PM) liheng:2. When we save a file in ODF, the pictures can not be compressed to save more space as we
(4:33:27 PM) liheng: usually insert image that it has been in compressing-format (like .png & .jpeg) . So can we
(4:33:27 PM) liheng: make a new method for save .od* files, that it do only pack the media files in archive but not
(4:33:27 PM) liheng: compress them. So that we can save more time from compressing pictures,video,audio in saving
(4:33:27 PM) liheng: and uncompressing them in loading.
(4:34:36 PM) liheng: Last IRC, We talk about the Performance server, but Malte and odf-mib think we can do a report in CH2000 first
(4:35:32 PM) liheng: I am very greet. So we can plan to work out first report show User Experience Index for OOo
(4:36:04 PM) xiuzhi: And AnsyLoading reviewer candidate.
(4:36:30 PM) odf-mib: liheng: I have to apologize, but it is not clear to me to which report you are referring.
(4:36:45 PM) liheng: We must decide which version we evaluate,and which hotspots we focus
(4:37:18 PM) Matthias: xiuzhi: can you explain what "AnsyLoading" is / means, please ?
(4:38:12 PM) odf-mib: MHU: It's related to the 2nd agenda item. I suggest we clarify this when we reach it.
(4:38:25 PM) xiuzhi: mhu: for big document. to speed up the display
(4:38:31 PM) liheng: odf-mib:In last mail we talk about do benchmark testing automically, this report is the benchmark report and counting the User
(4:38:54 PM) liheng: ... User Experience Index for OOo
(4:39:44 PM) Dieter_: I think it would be good to have a short introduction of our new team members Frank (FrankL) and Stephan (sb):
(4:39:46 PM) Dieter_: Frank is from User Experience and will work on all the UX stuff and Stephan is from development and will focus on startup performance.
(4:39:55 PM) xiuzhi: mhu:IBM are going to open, but not be available until now. we are developing it by ourselves. because IBM would not to show us their source
(4:40:40 PM) Matthias: xiuzhi: thanks for your explanations [I know "Loading" but have never heard the term "Ansy"]
(4:40:46 PM) xiuzhi: And Dr. JackieSun ,His major is image processing
(4:40:54 PM) liheng: FrankL:Welcome!
(4:41:07 PM) FrankL: Hi
(4:41:07 PM) liheng: sb_:Thanks :)
(4:41:16 PM) sb_: hi folks
(4:41:30 PM) xiuzhi: mhu:using two threads to load.
(4:41:53 PM) Matthias: yes, welcome Frank, Stephan, and Sui Yinan
(4:42:15 PM) JackieSun: I find in MS Office, the size of saved image is depent on the size of rect which the image is inserted, the more big of the rect , the more size of saved image
(4:42:17 PM) liheng: odf-mib: And the User Experience Index is only one number to show whole performance of OOo for all developers and users
(4:42:52 PM) xiuzhi: JackieSun: a minute. the second agenda item, please waiting
(4:42:59 PM) liangjun: welcome Frank, Stephan, and Sui Yinan:)
(4:43:03 PM) JackieSun: ok
(4:43:12 PM) JackieSun: 3ks everyone
(4:43:49 PM) liheng: Which version we do first report with?
(4:44:42 PM) liheng: Xiuzhi and me think 3.0 is good for it
(4:45:02 PM) Matthias: yes, I think 3.0 is the most interesting nowadays
(4:45:16 PM) Dieter_: +1
(4:46:23 PM) liheng: We will start to choose some case and make a formula for counting the Index, and publish them next week
(4:46:46 PM) Matthias: sounds good
(4:47:42 PM) liheng: then we will do whole report in 2 weeks
(4:49:21 PM) liheng: Startup and Load/Save is mainly hotspots for first benchmark testing report
(4:49:48 PM) Dieter_: would be good to come up with a draft report first so that Frank could jump in an work with you
(4:50:28 PM) liheng: Dieter_: OK
(4:50:48 PM) Dieter_: liheng: thanks :-)
(4:51:28 PM) liheng: We will get the report at Jan,31th
(4:52:54 PM) liheng: All:Can we turn to the next?
(4:53:50 PM) xiuzhi: odf-mib: What is your idea?
(4:54:11 PM) odf-mib: About what?
(4:54:20 PM) liheng: When we save a file in ODF, the pictures can not be compressed to save more space as we
(4:54:20 PM) liheng: usually insert image that it has been in compressing-format (like .png & .jpeg) . So can we
(4:54:20 PM) liheng: make a new method for save .od* files, that it do only pack the media files in archive but not
(4:54:20 PM) liheng: compress them. So that we can save more time from compressing pictures,video,audio in saving
(4:54:20 PM) liheng: and uncompressing them in loading.
(4:54:51 PM) xiuzhi: odf-mib:the second item.
(4:55:11 PM) odf-mib: Okay. Let me check if I do understand it:
(4:55:35 PM) JackieSun: I find in MS Office, the size of saved image is depent on the size of rect which the image is inserted, the more big of the rect , the more size of saved image
(4:56:39 PM) odf-mib: Or, let's start with a question: Is the idea to
(4:56:55 PM) xiuzhi: JackieSun: two aspects. one is Liheng mentioned. the other is yours
(4:56:58 PM) odf-mib: a) save the files uncompressed,
(4:56:59 PM) Matthias: JackieSun: is there in (MSO) an option to save image in original size (instead of default actual used size) ?
(4:57:12 PM) odf-mib: b) to save them with a reduced resolution?
(4:57:13 PM) JackieSun: mhu, i think no
(4:57:28 PM) Matthias: JackieSun: okay, thanks
(4:57:44 PM) yugq: The .png or .jpg files can't be compressed in size anymore by zip format. But if we try to compress them, it just waste time to do nothing.
(4:58:09 PM) liheng: odf-mib:we compress all XML file and bind all media files behind the ZIP
(4:59:25 PM) liheng: So we can save time of compressing and uncompressing media files when load and save a ODF file
(4:59:26 PM) odf-mib: linheng: I'm not sure. I didn't check this but my understanding is that we store files that are already compressed (like JPEG or PNG) uncompressed in the zip file.
(5:00:03 PM) JackieSun: I agree with odf-mib
(5:00:35 PM) Matthias: odf-mib: I think, we have this "presentation optimizer" ? can we combine this somehow (to be defined) so that we can have this feature, and don't loose image resolution if the user wants so?
(5:00:55 PM) liheng: I mean the media files are not in ZIP:)
(5:01:18 PM) odf-mib: Sorry, I'm still not sure we all talk about the same.
(5:01:58 PM) odf-mib: We are talking about compression, and we are talking about the resolution of the image size.
(5:02:07 PM) Matthias: yes, both
(5:02:16 PM) liheng: * ZIPPED *
(5:02:16 PM) liheng: * XML files *
(5:02:16 PM) liheng: *Media files*
(5:02:29 PM) JackieSun: the media files is not in ZIP and the jpeg file is in, is it ?
(5:03:33 PM) xiuzhi: all of the image and media files are out of the Zip
(5:03:44 PM) xiuzhi: That is LiHeng's mean
(5:03:48 PM) yugq: When save a doc, before zip all files into a odf, the media files like pictures is compressed format already. So compressed pictures don't need to compress a second time.
(5:04:53 PM) odf-mib: yugc: I strongly believe they aren't compressed a 2nd time.
(5:05:30 PM) liheng: odf-mib:but they are in the Zip file
(5:05:30 PM) odf-mib: yugc: ZIP allows you to store files uncompressed. We use that feature for meta.xml, and I strongly assume also for images.
(5:05:42 PM) odf-mib: yugc: If not, I would consider this to be a bug.
(5:06:51 PM) odf-mib: liheng: Yes, they are in the zip file. So it may require some more time to save them on disk when a presentation is stored. That's is saving time. But not time required for compression.
(5:07:55 PM) odf-mib: liheng: One can also just reference a image in Impress rather than embedding it. In this case, one the link to the image is stored, but not the image itself.
(5:08:17 PM) odf-mib: liheng: Is something like this what you have in mind?
(5:09:12 PM) yugq: odf-mib: But in fact, the .jpg & .png like files is a compressed format. When we compress a jpg file to a zip, the size would be close. But zip a file comsume time. So we could not zip a jpg file.
(5:09:43 PM) FrankL: Most times graphic keep untouched in a document. But when saving a document they will be stored again and again. Could this be avoided to save time?
(5:10:12 PM) xiuzhi: We want to save the saving time when the image is embeded , how to do that?
(5:10:35 PM) odf-mib: yugc: Zip allows you to store files without compression. In this case, no time is required for compression. Only the data needs to be copied into the file.
(5:10:45 PM) liheng: yugq:images in zip is same file as it original size
(5:11:50 PM) yugq: odf-mib, yes. I got you now. Thank you!:)
(5:12:12 PM) liheng: odf-mib:I think image can save out of ZIP and in a mapping format.
(5:13:26 PM) JackieSun: can the performance be increase by not saving the jpg files in a ZIP?
(5:14:05 PM) odf-mib: liheng, JackieSun: This option does exist already. Image can be inserted by a reference, rather than being embedded.
(5:14:31 PM) odf-mib: The issue with this is the user experience than copying file from one place to another.
(5:15:20 PM) JackieSun: OK
(5:15:39 PM) FrankL: Could we handle graphics which are already inside the doc zip as a reference? Then we do not have to store them again and again.
(5:15:39 PM) odf-mib: As a side note: I've just dumped a file containing an image. Here is an extract:
(5:15:54 PM) odf-mib: 11123 Defl:N 1708 85% 01-08-09 12:15 842340f8 Pictures/200000B100000FE500000EF9FF04DDF4.svm
(5:15:57 PM) odf-mib: 103 Stored 103 0% 01-08-09 12:15 d0f5f678 Pictures/100002000000000A0000000ADDA84F49.gif
(5:16:33 PM) odf-mib: So, jpg's are just stored, while SVM files (which are not compressed by itself) get compressed by ZIP.
(5:16:37 PM) liheng: odf-mib:Yes, so we can package image behind ZIP part
(5:17:39 PM) liheng: I think we need not compress and media file to reduce size of file.
(5:18:31 PM) xiuzhi: now odf = zip(xmles+ images+medias). Can it be :odf=one zip file(zipped xmles) + images+medias. ? Is this your mean LiHeng?
(5:18:55 PM) sb_: liheng: add data to the end of a zip file, after the data that follows the zip protocol? would that not break standard zip tools reading/modifying odf files? is it worth that?
(5:18:57 PM) liheng: xiuzhi:Yes!
(5:20:21 PM) odf-mib: liheng: Would the images be separate files, or appened to the zip as _sb assumes?
(5:20:24 PM) liheng: sb_:Yes it is a problem i worried,but it can save time when we loading and saving a document.
(5:20:59 PM) sb_: liheng: can it save so much time that we should even consider it?
(5:21:32 PM) JackieSun: Liheng: I think it is not a good idea. When a user want copy them to another PC, he should select some files but not one, isn't it?
(5:21:32 PM) liheng: I think so.
(5:21:50 PM) Matthias: liheng: how can it save time? you need to load the image anyway, either from zip-container or from disk ?
(5:23:07 PM) Matthias: ...and yes, with an external reference, a user would not easily know what to copy (it is not one file)
(5:23:20 PM) odf-mib: mhu: For loading, you are right. And I think we can even not save time while saving. It should not make a difference whether we store uncompressed data in the zip file, or append it to it. The amount of data that needs to be stored is the same in both cases.
(5:23:25 PM) liheng: Matthias:we can gather all media file in a section.
(5:24:06 PM) Matthias: liheng: I dont understand what you mean, can you explain ?
(5:24:19 PM) odf-mib: liheng, all: Before we discuss the options, I would like to understand if we want to save time while loading, or while saving a document.
(5:25:07 PM) liheng: Matthias:I send some details to you all after this meeting,:)
(5:25:35 PM) liheng: To explain how to save some time
(5:25:43 PM) Matthias: liheng: okay, yes we can discuss this offline
(5:25:51 PM) xiuzhi: +1
(5:26:00 PM) liangjun: :)
(5:26:06 PM) liheng: Yes, I will send it to performance mailing list
(5:26:21 PM) liheng: odf-mib:Thank you!
(5:26:29 PM) Matthias: good, so everyone can participate
(5:26:45 PM) sb_: liheng: performance mailing list = performance@tools.openoffice.org?
(5:26:54 PM) Matthias: sb_: yes
(5:26:56 PM) liheng: sb_: Yes
(5:27:14 PM) liheng: sb_:Thanks for your attending again
(5:27:17 PM) liheng: :)
(5:27:23 PM) JackieSun: ok, let's discuss how to deal with the high-res images next time
(5:27:42 PM) Matthias: okay
(5:27:54 PM) liheng: OK, that all today for me
(5:27:58 PM) xiuzhi: JackieSun: You can email your idea to the performance mailinglist
(5:28:08 PM) JackieSun: xiuzhi: ok
(5:28:21 PM) Matthias: yes, that would probably be good
(5:28:45 PM) Matthias: okay, then see you next week; bye all
(5:28:56 PM) yugq: bye all!
(5:28:58 PM) JackieSun: bye all
(5:29:01 PM) odf-mib: by all!
(5:29:03 PM) liheng: All:see you next time.
(5:29:03 PM) liangjun: bye all!
(5:29:12 PM) FrankL: bye!
(5:29:16 PM) sb_: bye
(5:29:51 PM) xiuzhi: bye

Go back