|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | PNG Options dialog has "fastest" and "slowest" terms reversed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Draw | Reporter: | mdw-bugzilla | ||||
| Component: | save-export | Assignee: | AOO issues mailing list <issues> | ||||
| Status: | CONFIRMED --- | QA Contact: | |||||
| Severity: | Minor | ||||||
| Priority: | P3 | CC: | issues, jza, rb.henschel | ||||
| Version: | 3.4.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Windows, all | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
No, it is correct. The needed time is not the pure loading, but uncompressing the file. But the question is, whether the file size and the time is significant different at all in png format. Also, "loading" is ambiguous. If you are loading a file over the network, then the least compression (largest size) might also be the slowest. But if you are loading from fast local storage (and have a slower CPU) then the I/O time might be small compared to the computation time involved in decompression. In any case I wonder if we should be making any load-time claims here at all, since it does depend on the details of the user's storage and CPU, things we do not know. Changing the bug to confirmed, even if the statements are true. I can verify the report is valid. Awaiting resolution. |
Created attachment 80373 [details] PNG Options dialog Dialog reads: 0 is biggest file size and fastest loading. 9 is smallest file size and slowest loading. Dialog should read: 0 is biggest file size and slowest loading. 9 is smallest file size and fastest loading.