On Mac OS X retina displays, photos in digikam look pretty pixelized, because each logical pixel actually consists of 2x2 physical pixels, with correspondingly sharp borders. This is due to the fact that Qt reports only half of the actual resolution to the application, so that pixel-based layouts do not get unreadable. Qt then handles native resolution for UI elements, rendering e.g. fonts at native resolution. Also, if pixmaps have a higher resolution, Qt renders them at native resolution. However, at present, the pixmaps that digikam provides to Qt are constructed at logical resolution. I have patched digikam to provide higher resolution pixmaps and would like to contribute this patch. It makes use of the fact full resolution images are loaded if "Embedded preview loads full-sized images" is set. The displayed pixmaps in preview and slide show are then made large enough to contain the full resolution preview image (or a part of it), rather then just the (logical) screen pixels covered. By this, Qt scales the pixmap to match the physical screen resolution, giving a pretty brilliant picture on a Macbook Retina. The fix also changes the Info.plist to make Mac OS X aware that digikam can handle the high resolution. Reproducible: Always Steps to Reproduce: 1. Start digikam with a retina display (e.g. Macbook Retina) 2. Preview any 5+ MPixels photo Actual Results: The preview or slideshow are displayed pixelized, with logical pixels consisting of 2x2 physical pixels each. Expected Results: The preview should be displayed in native resolution, i.e. without blocking pixels.
Created attachment 87637 [details] use high res pixmaps on retina displays
Thanks for the patch. I appreciate all OSX patches, since i use Macbook pro here. In your patch, you have introduced a new Info.plist.in patched automatically by cmake at configuration time. What's this kind of type of file ? All file patched by cmake must use .in_cmake extension and must be located to core/cmake/templates subdir. Gilles Caulier
Created attachment 87641 [details] updated patch with correct path for Info.plist template
Sorry, I wasn't aware of this policy. The Info.plist template is by the cmake Mac OS X target to create the resource info for the bundle. This Info.plist needs to mark the application to be high resolution capable, which is the "NSPrincipalClass->NSApplication". There is a template included with cmake, which was used by digikam before, but that lacks this pair, so I had to provide a fixed one. In addition, I filled some of the fields like "License", which are also empty in the standard cmake template. An updated patch with the relocated Info.plist.in_cmake is attached.
Excellent... I will review and apply patch to git/master. Q: Do you know well OSX envirronnement. There are few topic to fix with digiKam as, for ex, the capability to load digiKam when a camear device or a memory card is plug to computer. This kind of feature work with iPhoto for ex, but i never found a way to implement it under OSX. Gilles Caulier
In Info.plist file, "signature" field is patched with "????". This string must not be empty instead ? Gilles Caulier
Git commit 54eeb3c49f3dba2d8a29eccf8c9150b1f42fcc7a by Gilles Caulier. Committed on 08/07/2014 at 15:36. Pushed by cgilles into branch 'master'. apply patch #87641 to handle Retina display properly under OSX with preview image mode. FIXED-IN: 4.2.0 A +38 -0 cmake/templates/Info.plist.in_cmake M +9 -0 digikam/CMakeLists.txt M +19 -11 libs/widgets/graphicsview/graphicsdimgitem.cpp M +53 -15 utilities/slideshow/slideshow.cpp http://commits.kde.org/digikam/54eeb3c49f3dba2d8a29eccf8c9150b1f42fcc7a
Thanks for pushing so fast! As for the "????" signature, that I actually kept from the standard template included in cmake-3.0 (MacOSXBundleInfo.plist.in), also I was also wondering why they put that. Regarding the device plugging, I will take a look. I haven't worked on that part in Mac OS X (yet), but it is actually an interesting problem :-).
Comment on attachment 87637 [details] use high res pixmaps on retina displays Some minor comments: - is the "cut-off" approach of float->int conversion by using int(float-value) preferable to using QRectF::toRect() which provides proper rounding? - maybe you can expand the comment a bit by adding some of the explanation from your mail so that the problem can be understood from the code and the comment
Axel, Do you see comment #9 from Marcel ? Can you make a new patch against git/master fixing reported points ? Gilles Caulier
Yes, sorry for the delay. I will switch to QRectF and also expand the comment, but I won't have time before Friday evening. Axel
Created attachment 87715 [details] Expanded comments and Qt rounding Please find attached a patch that fixes the issues raised by Marcel. The code now uses QRectF/QSizeF for rounding everywhere.
Git commit 6a7a0d543fdfdc7a8cbd379a641e67d20f808094 by Gilles Caulier. Committed on 13/07/2014 at 07:31. Pushed by cgilles into branch 'master'. apply patch #87715 from Axel Arnolda M +25 -7 libs/widgets/graphicsview/graphicsdimgitem.cpp M +20 -4 utilities/slideshow/slideshow.cpp http://commits.kde.org/digikam/6a7a0d543fdfdc7a8cbd379a641e67d20f808094
An unpleasant follow-up: I just noticed that the June 24 patch for the MacPorts kdelibs4 jeopardizes my patch. It makes rasterization the default rendering method rather than using the native rendering which is retina-capable. There are two ways to get the native rendering back, which are really MacPorts-specific: - either, one edits once more the Info.plist, and adds an environment variable "RasterOff". - or, one calls a static function of KApplication called doNotRaster before creating the KApplication. The latter approach definitely can't go into the main digikam source, since it is MacPorts-specific, and only for versions of kdelibs4 >= 4.12.5_1. Setting the environment variable won't harm, but looks a bit ad-hoc for those that compile kde themselves. It also can't be fixed in MacPorts at the moment, since MacPorts installs still digikam 3.5.0.
Using pre processor rules cannot fix the problem with your last patch ? Do you suggest to revert your patch ? Gilles Caulier
Created attachment 87795 [details] fix telling Macports' kdelibs not use rastering The retina patch itself is fine, therefore there is no need to revert it. But since Macports is the recommended installation route on Mac for digikam, the patch should also work with MacPorts, probably. To that aim the attached patch sets the environment variable "RasterOff" in the Info.plist. This tells the Macports kdelibs to not use raster rendering and thus allows retina resolution, and won't have any effect on the stock kdelibs, with which retina resolution should work anyways.
Created attachment 87796 [details] also make imageeditor and showfoto retina-capable This patch also enables retina rendering in the digikam image editor and the showfoto application.
Git commit cda1f5a7d81a2bd01803e5bd284e136a29234319 by Gilles Caulier. Committed on 18/07/2014 at 09:31. Pushed by cgilles into branch 'master'. apply patch #87795 to indicate to not use Raster rendering under OSX M +5 -0 cmake/templates/Info.plist.cmake.in http://commits.kde.org/digikam/cda1f5a7d81a2bd01803e5bd284e136a29234319
Git commit d8ab531034a6d25736676f47b177b9d43ba0bd6d by Gilles Caulier. Committed on 18/07/2014 at 09:33. Pushed by cgilles into branch 'master'. appply patch #87796 to support retina display under OSX with Image editor and Showfoto M +9 -0 showfoto/CMakeLists.txt M +35 -8 utilities/imageeditor/widgets/imagepreviewitem.cpp http://commits.kde.org/digikam/d8ab531034a6d25736676f47b177b9d43ba0bd6d
This patch that has been introduces into Digikam 4.2.0 has a significant disadvantage on my system (Linux, openSUSE 13.1, Flat Panel BenQ resolution 1920x1080). When "Preview Load Full Image Size" is set to true, I am getting on some photos strange patterns in the preview, which vanish only when I am increasing the preview to 50 or more percent. My photos have a size of 36 Mpx. Obviously the algorithm that reduces the image to the screen size, creates some kind of a moiree structure if the underlying picture has a regular pattern e.g. a brick wall. This did not happen with DK 4.1.0. Also I can confirm the grainy picture in the preview. These effects disappear if I set "Preview Full Image Size" to false. BUT in that case I am loosing almost totally the high resolution of the photos when taking a 100% view. I am downgrading to DK 4.1.0 .
Axel, Others report in digiKam announcement page are here : https://www.digikam.org/node/715#comment-20800 Perhaps a solution can to wrap specific code for OSX using pre-processor and branch older implementation for Linux ? Note : I cannot reproduce this problem here on Windows, Linux (Mageia), and OSX Gilles Caulier
Yes, preprocessor branching might be an option, it actually just needs to fix the scaling factor to 1 to get the old behavior, I think. I am right now a bit busy, but should be done soon. The reason of the reported problems might be that the patch relies on the Qt renderer to scale the pixmap. And that seems to perform very well on Mac OS X, but I can imagine that some renderers are worse. That might also explain why it only looks bad under some Linux versions - maybe one uses the native renderer, another the GL renderer or similar. Axel
*** Bug 338138 has been marked as a duplicate of this bug. ***
Should we reopen this bug as a reminder? Or reopen bug 338138?
Christoph, You are right. I reopened bug 338138 which is more appropriate... Gilles Caulier
Axel, We waiting your patch to reopened bug 338138 including preprocessor wrap for OSX. Gilles Caulier
You mean that at some place you call drawPixmap with a target rectangle that has a different size than the pixmap? And that is necessary for proper display on MacOS? Indeed, on Linux we absolutely avoid that technique. Pixmaps are never scaled, images are scaled as DImg or QImage and converted to QPixmap readily scaled.
Yes, indeed, see http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/ . Basically, MacOSX reports only have of the physical resolution on retina displays, so that applications that were not build for high resolution screens work. At the same time, the system's renderer accepts higher resolution bitmaps and draws them at full resolution. There is something to that approach, since e.g. Chrome under Linux is hardly usable on a HiDPI monitor, as the menu font pixel sizes are fixed. Most KDE applications work fairly well, but even there I encounter pixel-based layout from time to time. Often, menus are too small to display all text, and so on. The problem is that you are depending on the backend scaling. Apple's implementation does a pretty good job, but it seems some Linux backends don't.
Created attachment 88275 [details] patch to use the Qt scaling only in MacOSX Here is a patch that should use pixmaps of logical screen pixel size for any other platform than MacOSX. It simply sets the pixel ratio to 1 for non-MacOSX, which results in the old behavior. If we ever get digikam on iOS/Android, we would need some more complex logic, though... However, I don't have a Linux box to test. I tested that the introduced define USE_QT_SCALING works as intended, but cannot really check that it is not set under Linux. Would be great if someone under Linux can test the patch.
Axel, I would be happy to test the patch on my system (Linux openSUSE 13.1). Unfortunately I don't know how to apply the patch. I just downloaded digikam-4.0.0.tar.bz2 from the kde repository, untared it and compiled the stuff. Can you give me instructions on how to apply the patch ? Regards, Robert On 08/16/2014 09:31 PM, Axel wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #29 from Axel <arnolda747@gmail.com> --- > Created attachment 88275 [details] > --> https://bugs.kde.org/attachment.cgi?id=88275&action=edit > patch to use the Qt scaling only in MacOSX > > Here is a patch that should use pixmaps of logical screen pixel size for any > other platform than MacOSX. It simply sets the pixel ratio to 1 for non-MacOSX, > which results in the old behavior. If we ever get digikam on iOS/Android, we > would need some more complex logic, though... > > However, I don't have a Linux box to test. I tested that the introduced define > USE_QT_SCALING works as intended, but cannot really check that it is not set > under Linux. Would be great if someone under Linux can test the patch. >
Robert, The patch must be applied only against current code from git/master (next 4.3.0). I do it on my core computer used to develop : [gilles@localhost core]$ pwd /mnt/devel/GIT/4.x/core [gilles@localhost core]$ ls -al total 9100 drwxr-xr-x 14 gilles gilles 4096 août 17 12:09 ./ drwxr-xr-x 9 gilles gilles 4096 août 8 18:54 ../ -rw-rw-r-- 1 gilles gilles 4842 août 17 12:05 0001-Use-Qt-scaling-only-under-MacOSX.patch -rw-r--r-- 1 gilles gilles 13544 août 16 18:01 AUTHORS -rw-r--r-- 1 gilles gilles 9012678 août 4 14:39 ChangeLog drwxr-xr-x 4 gilles gilles 4096 juil. 17 11:06 cmake/ -rw-r--r-- 1 gilles gilles 85044 août 8 18:54 CMakeLists.txt -rw-r--r-- 1 gilles gilles 18011 janv. 4 2014 COPYING -rw-r--r-- 1 gilles gilles 1327 janv. 4 2014 COPYING-CMAKE-SCRIPTS -rw-r--r-- 1 gilles gilles 26527 janv. 4 2014 COPYING.LIB drwxr-xr-x 8 gilles gilles 4096 juil. 17 11:06 data/ drwxr-xr-x 2 gilles gilles 4096 janv. 4 2014 databaseserver/ -rw-r--r-- 1 gilles gilles 911 janv. 4 2014 DESIGN drwxr-xr-x 14 gilles gilles 4096 août 16 14:30 digikam/ drwxr-xr-x 8 gilles gilles 4096 août 17 12:09 .git/ -rw-r--r-- 1 gilles gilles 52 janv. 4 2014 .gitignore -rw-r--r-- 1 gilles gilles 17372 mars 24 11:10 HACKING drwxr-xr-x 7 gilles gilles 4096 mai 10 14:34 imageplugins/ -rw-r--r-- 1 gilles gilles 87 janv. 4 2014 INSTALL drwxr-xr-x 2 gilles gilles 4096 juin 2 14:44 kioslave/ -rw-r--r-- 1 gilles gilles 79 janv. 4 2014 .krazy drwxr-xr-x 18 gilles gilles 4096 janv. 28 2014 libs/ -rw-r--r-- 1 gilles gilles 101 janv. 4 2014 Mainpage.dox -rwxr-xr-x 1 gilles gilles 267 janv. 4 2014 Messages.sh* -rw-r--r-- 1 gilles gilles 1115 août 16 17:32 NEWS drwxr-xr-x 4 gilles gilles 4096 août 4 14:39 project/ -rw-r--r-- 1 gilles gilles 9456 août 16 14:30 README drwxr-xr-x 5 gilles gilles 4096 août 16 14:30 showfoto/ drwxr-xr-x 8 gilles gilles 4096 juil. 17 11:06 tests/ -rw-r--r-- 1 gilles gilles 3073 juil. 17 11:06 TODO -rw-r--r-- 1 gilles gilles 279 janv. 4 2014 TODO.FACE -rw-r--r-- 1 gilles gilles 713 janv. 4 2014 TODO.MYSQLPORT -rw-r--r-- 1 gilles gilles 1348 janv. 14 2014 TODO.TABLEVIEW -rw-r--r-- 1 gilles gilles 2391 janv. 4 2014 TODO.TAGMNGR drwxr-xr-x 20 gilles gilles 4096 juil. 17 11:06 utilities/ [gilles@localhost core]$ patch -p1 < 0001-Use-Qt-scaling-only-under-MacOSX.patch patching file CMakeLists.txt patching file digikam/utils/config-digikam.h.cmake.in patching file libs/widgets/graphicsview/graphicsdimgitem.cpp patching file utilities/imageeditor/widgets/imagepreviewitem.cpp patching file utilities/slideshow/slideshow.cpp [gilles@localhost core]$ If you want to do it, forget official release tarball and checkout code from git KDE serveur, as explained here : https://www.digikam.org/download?q=download/GIT Note : using last code, you will be able to test fixes quickly and you will use last improvements/features before official release. Gilles Caulier
Axel, Last patch compile and run fine on my Linux box, but as i said in others place, you original patch never introduce a dysfunction on my computer. Gilles Caulier
Robert, I will commit changes in git/mast with Axel patch. Like this you will be able to run current code with all modification as well... Gilles Caulier
Git commit 2e03ccdb9319e40b8e40cabea569c8656053171f by Gilles Caulier. Committed on 17/08/2014 at 10:24. Pushed by cgilles into branch 'master'. apply new patch #88275 from Axel Arnold about Retina display support will be only managed under OSX, not Linux or Windows. Related: bug 338138 M +7 -0 CMakeLists.txt M +3 -0 digikam/utils/config-digikam.h.cmake.in M +5 -0 libs/widgets/graphicsview/graphicsdimgitem.cpp M +5 -0 utilities/imageeditor/widgets/imagepreviewitem.cpp M +5 -1 utilities/slideshow/slideshow.cpp http://commits.kde.org/digikam/2e03ccdb9319e40b8e40cabea569c8656053171f
Gilles, sounds good to me. Can I download the patched version somewhere; I mean the complete patched digikam source code? I would like to use 4.2.0 patched as production code on my box. Thanks. Robert On 08/17/2014 12:24 PM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #33 from Gilles Caulier <caulier.gilles@gmail.com> --- > Robert, > > I will commit changes in git/mast with Axel patch. Like this you will be able > to run current code with all modification as well... > > Gilles Caulier >
next 4.3.0 source source is 4.2.0 + some fixes including this one. There is no huge changes with 4.3.0. Checkout source code from Git repository, as explained in this page : https://www.digikam.org/download?q=download/GIT Gilles Caulier
Thanks, I just compiled the patched 4.3.0 on my box (openSUSE 13.1) without any problems. The strange artifacts and also the grainy preview are gone away. So I will stay with DK 4.3.0 from git. On 08/17/2014 03:23 PM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #36 from Gilles Caulier <caulier.gilles@gmail.com> --- > next 4.3.0 source source is 4.2.0 + some fixes including this one. There is no > huge changes with 4.3.0. > > Checkout source code from Git repository, as explained in this page : > > https://www.digikam.org/download?q=download/GIT > > Gilles Caulier >
Ok, so the problem seems to be the Qt scaling, which sometimes works well and sometimes doesn't. Out of curiosity, could the Linux users try out which Qt engine causes the problem? The engine can be chosen by "export QT_GRAPHICSSYSTEM <system>", where system is either "native", "raster" or "GL". To get the higher resolution pixmaps even with my latest patch, just manually define USE_QT_SCALING in digikam/utils/config-digikam.h.cmake.in.
Axel, on my system echo $QT_GRAPHICSSYSTEM delivers raster. open GL (experimental) screws up the kde system. On 08/17/2014 04:06 PM, Axel wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #38 from Axel <arnolda747@gmail.com> --- > Ok, so the problem seems to be the Qt scaling, which sometimes works well and > sometimes doesn't. > > Out of curiosity, could the Linux users try out which Qt engine causes the > problem? The engine can be chosen by "export QT_GRAPHICSSYSTEM <system>", where > system is either "native", "raster" or "GL". To get the higher resolution > pixmaps even with my latest patch, just manually define USE_QT_SCALING in > digikam/utils/config-digikam.h.cmake.in. >
Compositing type/Qt graphics system (System Settings > Desktop Effects > Advanced) doesn't seem to make a difference to 4.2.0 unpatched on my system. Off-topic, why bother having the ".0" in digiKam's version number if you don't use it? Bug-fix releases should be 4.2.1.
In the version from GIT I have: #cmakedefine USE_QT_SCALING 1 is that what you mean? On 08/17/2014 04:06 PM, Axel wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #38 from Axel <arnolda747@gmail.com> --- > Ok, so the problem seems to be the Qt scaling, which sometimes works well and > sometimes doesn't. > > Out of curiosity, could the Linux users try out which Qt engine causes the > problem? The engine can be chosen by "export QT_GRAPHICSSYSTEM <system>", where > system is either "native", "raster" or "GL". To get the higher resolution > pixmaps even with my latest patch, just manually define USE_QT_SCALING in > digikam/utils/config-digikam.h.cmake.in. >
Yes, exactly. Just replace #cmakedefine by #define, then the Qt scaling should be in use. After that, you can start digikam with the three possible rendering engines and see whether they make a difference under Linux. Thanks for checking!
Axel, QT_GRAPHICSSYSTEM is not set on my system... Gilles Caulier
Next digiKam version will be 4.3.0, and it will not be a simple bugfix release only... Gilles Caulier
Sorry, Axel: if I replace #cmakedefine by #define I again get the old problem: artifacts in regions with repeating regular structures and grainy preview. keeping #cmakedefine USE_QT_SCALING 1 in digikam/utils/config-digikam.h.cmake.in removes the problem. On 08/17/2014 07:02 PM, Axel wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #42 from Axel <arnolda747@gmail.com> --- > Yes, exactly. Just replace #cmakedefine by #define, then the Qt scaling should > be in use. After that, you can start digikam with the three possible rendering > engines and see whether they make a difference under Linux. Thanks for > checking! >
(In reply to Robert Zeller from comment #45) > #cmakedefine by #define > > I again get the old problem: artifacts in regions with repeating regular > structures and grainy preview. Yes, that should be the case. My question was, if setting "export QT_GRAPHICSSYSTEM native" (or replacing native with GL oder raster) before running digikam does change anything. Usually, this environment variable is not set, but it can be used to change the default renderer (https://forum.kde.org/viewtopic.php?f=66&t=90821). As far as I understood, some distributions recently changed the default renderer from "native" to "raster", and I would simply like to know whether the the graphicssystem makes a difference. So, can you try through and see whether the artifacts also disappear with one of the rendering systems? Thanks, Axel
(In reply to Gilles Caulier from comment #43) > Axel, > > QT_GRAPHICSSYSTEM is not set on my system... > > Gilles Caulier Well, it doesn't need to be; in this case, the systemwide default applies. With a plain Qt, that would be "native" under Linux, but Linux distributions can compile in a different default renderer. Unfortunately, I have not found any hint how one can figure out which renderer QT by default uses.
I tried "native" and "raster" and there is no noticeable difference between the two. I can't use GL because that freezes my kde for some reason; a known behavior in openSUSE on some hardware. On 08/17/2014 08:59 PM, Axel wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #46 from Axel <arnolda747@gmail.com> --- > (In reply to Robert Zeller from comment #45) > >> #cmakedefine by #define >> >> I again get the old problem: artifacts in regions with repeating regular >> structures and grainy preview. > Yes, that should be the case. My question was, if setting "export > QT_GRAPHICSSYSTEM native" (or replacing native with GL oder raster) before > running digikam does change anything. Usually, this environment variable is not > set, but it can be used to change the default renderer > (https://forum.kde.org/viewtopic.php?f=66&t=90821). > > As far as I understood, some distributions recently changed the default > renderer from "native" to "raster", and I would simply like to know whether the > the graphicssystem makes a difference. So, can you try through and see whether > the artifacts also disappear with one of the rendering systems? > > Thanks, > Axel >
Robert, Look digiKam options from CLI : [gilles@localhost reports]$ digikam --help-qt Usage: digikam [Qt-options] [KDE-options] [options] Manage your photographs like a professional, with the power of open source Generic options: --help Show help about options --help-qt Show Qt specific options --help-kde Show KDE specific options --help-all Show all options --author Show author information -v, --version Show version information --license Show license information -- End of options Qt options: --display <displayname> Use the X-server display 'displayname' --session <sessionId> Restore the application for the given 'sessionId' --cmap Causes the application to install a private color map on an 8-bit display --ncols <count> Limits the number of colors allocated in the color cube on an 8-bit display, if the application is using the QApplication::ManyColor color specification --nograb tells Qt to never grab the mouse or the keyboard --dograb running under a debugger can cause an implicit -nograb, use -dograb to override --sync switches to synchronous mode for debugging --fn, --font <fontname> defines the application font --bg, --background <color> sets the default background color and an application palette (light and dark shades are calculated) --fg, --foreground <color> sets the default foreground color --btn, --button <color> sets the default button color --name <name> sets the application name --title <title> sets the application title (caption) --testability load the testability framework --visual TrueColor forces the application to use a TrueColor visual on an 8-bit display --inputstyle <inputstyle> sets XIM (X Input Method) input style. Possible values are onthespot, overthespot, offthespot and root --im <XIM server> set XIM server --noxim disable XIM --reverse mirrors the whole layout of widgets --stylesheet <file.qss> applies the Qt stylesheet to the application widgets --graphicssystem <system> use a different graphics system instead of the default one, options are raster and opengl (experimental) --qmljsdebugger <port> QML JS debugger information. Application must be built with -DQT_DECLARATIVE_DEBUG for the debugger to be enabled [gilles@localhost reports]$ This one permit to switch between rendering method : --graphicssystem <system> use a different graphics system instead of the default one, options are raster and opengl (experimental) Gilles Caulier
(In reply to Robert Zeller from comment #48) Strange, since Gilles said that it works ok for him. So it seems there is some difference in how Qt renders pixmaps with higher resolution, which is not just the rendering engine. Now, I wonder what makes the difference... In any case, with the patch, it is disabled by default and works under Linux. > I tried "native" and "raster" and there is no noticeable difference > between the two. I can't use GL because that freezes my kde for some > reason; a known behavior in openSUSE on some hardware. > > On 08/17/2014 08:59 PM, Axel wrote: > > https://bugs.kde.org/show_bug.cgi?id=337231 > > > > --- Comment #46 from Axel <arnolda747@gmail.com> --- > > (In reply to Robert Zeller from comment #45) > > > >> #cmakedefine by #define > >> > >> I again get the old problem: artifacts in regions with repeating regular > >> structures and grainy preview. > > Yes, that should be the case. My question was, if setting "export > > QT_GRAPHICSSYSTEM native" (or replacing native with GL oder raster) before > > running digikam does change anything. Usually, this environment variable is not > > set, but it can be used to change the default renderer > > (https://forum.kde.org/viewtopic.php?f=66&t=90821). > > > > As far as I understood, some distributions recently changed the default > > renderer from "native" to "raster", and I would simply like to know whether the > > the graphicssystem makes a difference. So, can you try through and see whether > > the artifacts also disappear with one of the rendering systems? > > > > Thanks, > > Axel > >
Gilles, I repeated my tests; results are as follows: 1. #define USE_QT_SCALING 1 in core/digikam/utils/config-digikam.h.cmake.in run with digikam --graphicssystem native ; raster ; opengl in all three cases I get the artifacts and the grainy structure 2. #cmakedefine USE_QT_SCALING 1 in core/digikam/utils/config-digikam.h.cmake.in run with digikam --graphicssystem native ; raster ; opengl the artifacts as well as the grainy structure disappear in all three cases. When running digikam from the command line I get in all cases the following error messages: digikam --graphicssystem=native Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath) QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. libv4l2: error getting pixformat: Invalid argument digikam(12497)/KIPI (loading) KIPI::PluginLoader::init: Plugin had an empty name or library file - this should not happen. I always had these error messages, which did not affect the functionality of DK. I am using a AMD - Graphics card: AMD Radeon HD 5700 Series Robert On 08/17/2014 09:29 PM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=337231 > > --- Comment #49 from Gilles Caulier <caulier.gilles@gmail.com> --- > Robert, > > Look digiKam options from CLI : > > [gilles@localhost reports]$ digikam --help-qt > Usage: digikam [Qt-options] [KDE-options] [options] > > Manage your photographs like a professional, with the power of open source > > Generic options: > --help Show help about options > --help-qt Show Qt specific options > --help-kde Show KDE specific options > --help-all Show all options > --author Show author information > -v, --version Show version information > --license Show license information > -- End of options > > Qt options: > --display <displayname> Use the X-server display 'displayname' > --session <sessionId> Restore the application for the given 'sessionId' > --cmap Causes the application to install a private color > map on an 8-bit display > --ncols <count> Limits the number of colors allocated in the color > cube on an 8-bit display, if the application is > using the QApplication::ManyColor color > specification > --nograb tells Qt to never grab the mouse or the keyboard > --dograb running under a debugger can cause an implicit > -nograb, use -dograb to override > --sync switches to synchronous mode for debugging > --fn, --font <fontname> defines the application font > --bg, --background <color> sets the default background color and an > application palette (light and dark shades are > calculated) > --fg, --foreground <color> sets the default foreground color > --btn, --button <color> sets the default button color > --name <name> sets the application name > --title <title> sets the application title (caption) > --testability load the testability framework > --visual TrueColor forces the application to use a TrueColor visual on > an 8-bit display > --inputstyle <inputstyle> sets XIM (X Input Method) input style. Possible > values are onthespot, overthespot, offthespot and > root > --im <XIM server> set XIM server > --noxim disable XIM > --reverse mirrors the whole layout of widgets > --stylesheet <file.qss> applies the Qt stylesheet to the application > widgets > --graphicssystem <system> use a different graphics system instead of the > default one, options are raster and opengl (experimental) > --qmljsdebugger <port> QML JS debugger information. Application must be > built with -DQT_DECLARATIVE_DEBUG for the debugger > to be > enabled > [gilles@localhost reports]$ > > This one permit to switch between rendering method : > > --graphicssystem <system> use a different graphics system instead of the > default one, options are raster and opengl (experimental) > > Gilles Caulier >