WebSite Information > Comments, Suggestions & Questions

Another bad gif

<< < (2/2)

Dave Yeo:

--- Quote from: Flashback on October 30, 2024, 09:26:16 pm ---No matter how 'broken' the file is, it's the job of the browser to handle it gracefully.

--- End quote ---

Sure, do you want to write a few video drivers so we can do the drawing during the horizontal refreshes? And then backport the fix from Firefox 80 or so, might have to write a Rust compiler too.

Martin Iturbide:
Hello Dave

I just replaced the gif file.

So, you think this issue is more about related the video drivers? I thought it was more about how the software renders the image. Is it PMView or other software that can open the gif file spiking up the processor?

Update: I just tried PMView to open the gif and does not spikes up the processor, and if I save it with PMView it fixes the file too. On Firefox this page spikes the processor because I attached also the fault gif. Doodble does not have this issue. Is there a special way (own library or other DLL) how Firefox/Seamonkey renders the gif files?

Regards

Dave Yeo:
Hi Martin, it is a combination of things. A bug in the code where some gif's are treated like they are animated, and due to our lack of support for the way that Mozilla started drawing the canvas during the vertical refresh cycle, the bug shows up on our platform more as excess CPU usage then other platforms. By the time Mozilla fixed the bug, the code base had changed too much to do a simple backport of the fix.
Other software displays the gif's fine including Firefox 38.

Navigation

[0] Message Index

[*] Previous page