(*** This bug was imported into bugs.kde.org ***) Package: khtml Version: 4.0 (using KDE 3.0.0 ) Severity: wishlist Installed from: Mandrake RPMs Compiler: gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk) OS: Linux (i686) release 2.4.18-6mdk OS/Compiler notes: This is an RFE to display interlaced PNG images gradually. At the moment konqueror downloads the whole picture first and displays it afterwards. I have put 3 PNGs with Adam7 interlacing at http://www.uni-weimar.de/~hielsch1/png-test/ (Submitted via bugs.kde.org) (Called from KBugReport dialog. Fields KDE Version manually changed)
This would actually require re-writing a png loader in KDE (hence the change of priority) . But the much better fix would be if Qt's png loader was incremental, so actually this could be considered a Qt bug.
Have we annover testpage to test this bug later? The page that was here in the bug is not online!! Sven
Seems like the main server is down. But the alternative server is still working. Use http://gonzo.uni-weimar.de/~hielsch1/png-test/ Regards, Helge
An Adam7-interlaced PNG is: http://www.koffice.org/kword/pics/kword_classic_picture.png (The small version of the picture is in Adam7 too.) All this can be accessed by http://www.koffice.org/kword/screenshots.php (If you need more Adam7 files, you can use Gimp.) Have a nice day!
Still valid as of KDE 3.2
I am increasing the severity of this bug report from "wishlist" to "bug". The reason is that QImageDecoder::inputFormats() claims to know PNG, so incremental decoding and displaying of PNG files should work now, as JPEG files are using the same mechanism. (I have not tested with Qt alone, so I cannot be sure if the real problem would not be in Qt.) Have a nice day!
Well, we have a conflict here. Qt has everything the whole code to do progreesive loading, inclusive Adam7-interlaced, but it announces that it is finished, when the whole image is finished. :-( (I do not knwo how to bug Trolltech without getting an answer of the type: "That was not our intend. If anybody has an idea...) Have a nice day!
This works for me using KDE 3.2.3 + QT 3.3.2. Can you still reproduce this?
WFM/KDE 3.2.3 & qt3-common-3.3.2-16mdk
Do you can really see it progressively? Sorry, I do not, not even with KDE CVS HEAD (and I have a Qt snapshot that is post-Qt 3.3.2, so it should not be the problem either.) Have a nice day!
Yes, I could see it progressively, but Konqueror was using gwenview's kpart. Now I changed the settings back to "Embeddable Image Viewer" and now it does not load progressively anymore. Reopening.
Added pngtest.html to http://www.uni-weimar.de/~hielsch1/png-test/ for easier testing. Konqueror is always using its internal PNG viewer, if the PNGs are wrapped inside an HTML-Document.
> Konqueror is always using its internal PNG viewer, if the PNGs are wrapped inside an HTML-Document. If this is true then I have mysterious KDE/QT sources that don't exist ;-) Because the images are also loaded progressively within the html. It is very slow and X consumes 100% (similar to the now closed bug when loading large images) while loading but they _are_ loaded progressively. Gwenview's kpart does not exhibit this slowness. Let's see: KDE_3_2_BRANCH and QT snapshot from 2004-06-30 libpng 1.2.5 qt configured with -system-libpng
Tested it a bit more, using Konqueror with embeded viewers set to: 1st Gwenview's KPart 2nd embedded image viewer. Cache set to off. If I start a new intance of konqueror and open http://www.uni-weimar.de/~hielsch1/png-test/pngtest.html the PNGs are rendered non-interlaced. But if I open http://www.uni-weimar.de/~hielsch1/png-test/falten1.png first and then http://www.uni-weimar.de/~hielsch1/png-test/pngtest.html the PNGs inside of the HTML are rendered progressively. kdebase-3.2.3-9mdk, qt3-common-3.3.2-17mdk, libpng3-1.2.5-11mdk, gwenview_hack-1.1.3-0.1mdk
If it works with Gwenview, then perhaps the code has to be moved to be able to use it without Gwenview too. Have a nice day!
most likely will work in 4.0
It works both in KDE 3.5 and KDE4. The image are loaded progressively as expected.