[Xfce-bugs] [Bug 15288] Change image loading backend from GdkPixbuf to abydos

[bugzilla-daemon at xfce.org]

https://bugzilla.xfce.org/show_bug.cgi?id=15288

--- Comment #4 from Magnus Bergman <magnus.bergman at snisurset.net> ---
Another possible concern is that abydos cannot be used for image editing
(mentioned in bug 5796 and bug 14733). If an image is loaded into memory as a
bitmap (cairo image surface), then rotated, flipped and/or cropped, abydos
cannot write the changes back to the file (well cairo can write PNG but that's
it). IMHO it would be opening a can of worms to add image editing to an image
viewer. It could only flaky at best. For some formats it would be virtually
impossible to support. And there would be a lot of strange corner cases then it
isn't trivial to even know what to ideally do. For example if the user crops a
PDF file, should just the current page be cropped or all pages? What if other
pages have different orientation or even different sizes, what should happen?
It is  probable that users only expect it to work on small set of image formats
(the ones gdk-pixbuf is able to write), including JPEG. And for a lossy format
JPEG it can be suboptimal decode, edit and encode the image again since some
changes can be done without re-encoding and suffer further data loss. So I
suggest invoking some external editing tools for applying the changes. (But
honestly I think users who want to edit images should use a real image editor
instead.)

It sounds like a good idea to make it a compile time option to use abydos. I
could prepare a patch for that. But there is one thing that severely affects
the difficulty and complexity of the code: There are two approaches to
loading images (both with gdk-pixbuf and abydos), you could either provide the
complete content and get the complete image back in one synchronous operation.
That could be done in a thread so it doesn't need to be blocking if it's slow
for some reason (which might be a good idea anyhow since the current
asynchronous code might not be asynchronous enough considering bug 11577). That
would be quite simple to implement. The other way is to progressively feed data
to the loader as it becomes available and (in cases it's supported) get a
gradually loading image to display during the process. Currently Ristretto adds
all the complexity to almost support progressive loading, but actually doesn't
(nothing is displayed until the image is completely loaded). So that's the
intention here? I guess the only use case for progressive loading is very slow
internet connections. (But letting non-sandboxed code process potentially
malicious data from the internet could be considered a security hazard.) In
other cases it's probably preferable to wait until the whole image is available
before anything is displayed (which I guess is the reason why the code does
what is does today). I could fix the code so progressive loading works.
Otherwise I think what progressive loading should be axed in favor of the
simpler approach (for improved maintainability). Who has the final say on this?

-- 
You are receiving this mail because:
You are the assignee for the bug.