[digikam] [Bug 337231] New: use high resolution pixmaps on retina displays [patch]
Locked
123
123
 
|
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #40 from DrSlony <[hidden email]> --- 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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #41 from Robert Zeller <[hidden email]> --- 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 <[hidden email]> --- > 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. > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #42 from Axel <[hidden email]> --- 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! -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #43 from Gilles Caulier <[hidden email]> --- Axel, QT_GRAPHICSSYSTEM is not set on my system... Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #44 from Gilles Caulier <[hidden email]> --- Next digiKam version will be 4.3.0, and it will not be a simple bugfix release only... Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #45 from Robert Zeller <[hidden email]> --- 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 <[hidden email]> --- > 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! > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #46 from Axel <[hidden email]> --- (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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #47 from Axel <[hidden email]> --- (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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #48 from Robert Zeller <[hidden email]> --- 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 <[hidden email]> --- > (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 > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #49 from Gilles Caulier <[hidden email]> --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #50 from Axel <[hidden email]> --- (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 <[hidden email]> --- > > (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 > > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
[digikam] [Bug 337231] use high resolution pixmaps on retina displays [patch]
|
|
In reply to this post by Axel
https://bugs.kde.org/show_bug.cgi?id=337231
--- Comment #51 from Robert Zeller <[hidden email]> --- 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 <[hidden email]> --- > 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 > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |