https://bugzilla.xfce.org/show_bug.cgi?id=15288
--- Comment #4 from Magnus Bergman <magnus.berg...@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. _______________________________________________ Xfce-bugs mailing list Xfce-bugs@xfce.org https://mail.xfce.org/mailman/listinfo/xfce-bugs
