--- Comment #22 from trl...@hotmail.com ---
Nope. Not in open source. (In reply to comment #21)
> trlkly: No idea which "policy" thing you talk about, but maintainers of a
> codebase are free to decide that they are actively against fixing a valid bug
> in the software if this would create side effects ("reduces performance both
> for the server and for clients such as browsers") that they considered worse.
They are allowed to refuse patches if they think the patches have downsides,
yes, but not to arbitrarily declare that all such patches must have that
downside. And note the word "they" rather than "he." This was a single person
making the decision, without even entertaining the idea that someone might have
a way to handle it.
And, in fact, there are multiple ways of getting around the issues he stated.
There's no inherent reason that progressive JPEGs take longer to render than
baseline JPEGs. It isn't the case on any modern software. It isn't the case
that they must take up a lot more memory as, unlike thumbnailing, converting
between the two can be done without full decompression. Thus the memory
requirements are as low as you can stand having to go back to the disk to read
more of the file.
Furthermore, thumbnailing a progressive JPEG often requires less of the JPEG to
be rendered, since you only have to render up to the resolution just above the
thumbnail. Progressive JPEGs essentially have their own thumbnails baked in.
There are multiple solutions that could deal with this problem without causing
significant drain on the system. Most of them came in after the guy arbitrarily
closed the bug without waiting for ideas on how to mitigate the problems.
A bug should be left open if it is legitimate. Closing the bug prevents anyone
else from coming up with a solution that mitigates all problems.
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list